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EXECUTIVE  SUMMARY 


This  report  is  the  fourth  of  four  Editions  of  the  Program  Office  Guide  to  Ada.  Col¬ 
lectively.  these  editions  complement  the  Program  Manager’s  Guide  to  Ada,  ESD-TR-85- 
159,  dated  May  1985.  This  effort  was  sponsored  by  the  Air  Force  Computer  Resource 
Management  Technology  Program,  Program  Element  64740F,  Project  2526,  Software 
Engineering  Tools  and  Methods.  The  SEI  (Software  Engineering  Institute)  has  an  on¬ 
going  effort  to  study  Ada  related  issues  and  will  publish  handbooks  on  their  findings  on 
a  periodic  basis. 

The  goal  of  the  four  supplemental  editions  has  been  to  discuss  the  transition  of 
Ada  into  the  life  cycle  phases,  into  different  classes  of  software,  and  into  the  acquisition 
process.  Software  engineering  concepts,  methods,  standards,  and  environments  are  dis¬ 
cussed  extensively.  The  relationship  between  Ada  and  software  engineering  is  explored 
both  from  the  viewpoint  of  usage  and  tools.  Management  concerns  on  cost,  policy,  and 
progress  evaluation  are  also  reviewed. 

Edition  1  addressed:  policy,  run-time  efficiency,  run-time  support  environment  cus¬ 
tomization.  training.  Ada  program  design  languages,  and  conversion  of  non-Ada  code. 

Edition  2  addressed:  DoD  Standards  2167  and  2168,  guidelines  for  proposal  evalua¬ 
tion.  reusability  and  portability  considerations,  software  costing  models,  benchmarking 
efforts,  and  Ada  software  libraries. 

Edition  3  addressed:  maintenance  of  the  Ada  Standard.  Ada  Education  and  Train¬ 
ing  Study,  program  proving  and  verification,  environments,  tools,  interfaces,  and  compuler 
aided  software  engineering. 

Edition  4  discusses: 

•  Ada  usage  issues. 

•  policy  updates, 

•  progress  on  benchmarks. 

•  the  use  of  Ada  in  simulation, 

•  lessons  learned  on  Ada  projects, 

•  distributed  processing.  ' 

•  real-time  issues,  and 
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•  contractor  evaluation. 


A  well-written  Ada  program  is  supposed  to  satisfy  criteria  such  as  readability,  modu 
larity,  and  extendability.  The  proper  use  of  language  constructs  and  coding  style  enables 
the  code  to  meet  these  criteria.  Moreover,  practical  experience  on  Ada  projects  to  date 
has  also  validated  the  fact  that  Ada  “delivers”  on  many  of  the  software  engineering 
concepts  it  is  intended  to  support. 

Ada  technology  has  greatly  improved  during  the  last  few  years.  Inefficiency  and  tool 
immaturity  have  been  the  major  complaints  of  Ada  users  to  date.  Vendors  have  passed 
the  first  milestone,  validation,  and  are  now  concentrating  on  run-time  system  support 
and  performance  goals.  Standardized  sets  of  benchmark  suites  are  becoming  available, 
enabling  more  meaningful  comparisons  of  Ada  products.  As  experience  with  benchmarks 
continues  to  grow,  guidelines  are  emerging  on  their  installation  and  execution. 

Software  engineers  are  using  Ada  on  a  wide  variety  of  projects,  including  real  time 
systems,  distributed  systems,  and  simulation.  Ada  supports  both  traditional  real-time 
development  and  new,  more  flexible  approaches.  Some  designs  may  require  customized 
run-time  systems,  providing  support  for  the  unit  of  distribution,  internode  communi¬ 
cation  and  error  handling,  a  run-time  system  scheduler,  and  discrete  event  simulation. 
Research  shows  promise  of  a  hybrid  method  of  development  that  combines  the  advan 
tages  of  the  two  existing  methods. 

In  1987  a  major  policy  milestone  was  achieved  with  the  signing  of  Department  of 
Defense  (DoD)  Directives  3405.1  and  3405.2,  mandating  the  use  of  Ada  for  all  defense- 
related  software.  The  implementation  of  this  policy  should  serve  as  a  clear  signal  within 
the  DoD  and  industry  that  the  time  for  transition  to  Ada  is  now.  The  fact  that  contrac 
tors  must  now  use  Ada  has  motivated  studies  in  software  productivity  metrics  to  aid  in 
contractor  evaluation. 
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FOREWORD 


This  report  is  the  fourth  in  a  series  of  four  editions  that  supplement  the  Program 
Manager's  Guide  to  Ada,  ESD-TR-85-159,  published  by  The  Computer  Resource  Man¬ 
agement  Technology  Program  in  May,  1985.  The  introduction  of  Ada  as  the  mandated 
high  order  language  for  Mission  Critical  Computer  Programming  in  the  Department  of 
Defense  has  generated  a  need  for  clear,  concise  information  for  program  managers  and 
others  concerned  with  cost,  schedule,  and  performance  in  the  application  of  this  new 
language. 

The  intent  of  this  series  is  to  bring  Program  Office  personnel  up  to  date  on  facts 
presented  in  the  original  Program  Manager’s  Guide,  as  well  as  to  provide  a  more 
rounded  discussion  on  certain  subjects  presented  in  the  original  guide.  This  series 
of  four  reports  is  designed  for  the  program  manager  and  his  technical  staff.  It  is 
recommended  that  the  four  editions  comprising  this  report  be  kept  with  the  original 
Program  Manager's  Guide  to  Ada.  forming  a  ready  reference  to  Ada  and  Ada-related 
topics. 
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Section  22 

Ada  Usage  Issues 


To  use  the  Ada  standard  to  its  fullest,  it  is  important  to  understand  the  philosophy 
behind  the  development  of  Ada.  Good  usage  of  Ada  requires  disciplined  methodologies1, 
using  Ada  features  towards  the  application  of  the  methodologies,  and  good  programming 
style.  This  section  covers  how  Ada  supports  modern  software  engineering  p  ractices.  with¬ 
out  discussing  Ada  syntax.  Guidelines  for  Ada  programming  style  are  also  presented. 


22.1  Ada’s  Support  for  Software  Engineering 

Ada  was  designed  to  be  a  general-purpose  language,  facilitating  the  development 
of  reliable  and  maintainable  software.  It  was  designed  for  embedded  computer  systems, 
though  it  has  been  prov'i  useful  in  other  applications,  such  as  data  processing.  The 
language  provides  compile  time  detection  of  many  coding  errors  and  encourages  modern 
software  engineering  practices  to  ensure  reliable  code.  Readability  is  emphasized  through 
programming  conventions  and  proper  use  of  its  constructs. 

Ada  is  a  large  and  powerful  language.  A  programmer  need  not  use  all  of  the  features 
of  the  language  iri  every  program.  It  is  both  normal  and  appropriate  to  use  just  a  subset 
of  the  features.  To  use  Ada  to  its  fullest,  a  programmer  needs  proper  training  and  tools. 

Along  with  discussing  the  features  particular  to  Ada.  their  advantages  and  disad¬ 
vantages  will  be  pointed  ou*.  Run-time  efficiency,  discussed  in  Edition  1,  Section  3.2. 
will  not  be  further  discussed  here.  This  section  is  not  meant  to  be  a  catalog  of  Ada 
constructs:  only  selected  features  are  discussed.  These  features  are  organized  by  topic 
as  follows: 

•  Modular  structure. 

•  Separate  compilation. 

•  Abstraction. 

•  Structured  control. 

•  Reusability,  and 

•  Environment  specific  features. 

1  Programming  methodologies  have  been  discussed  in  Edition  1.  Section  5,  Ada  Program  Design 
l  anguage:  Edition  2,  Section  8.  DoD  STD-2167  and  Methodologies  for  Use  with  Ada;  and  Edition  2. 
Section  11.  Reusability  and  Portability. 
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The  most  versatile  language  feature  is  the  package,  different  aspects  of  which  are  illus 
trated  throughout  this  section. 

22.1.1  Modular  Structure 

In  many  languages  including  Ada,  a  large  program  will  be  broken  down  into  nu¬ 
merous  modules  to  make  it  easier  to  understand.  Modules  usually  perform  a  specific 
function  that  can  be  separate  from  the  rest  of  the  program.  If  modifications  need  to  be 
made,  modularity  makes  it  easier  to  isolate  the  changes.  The  Ada  view  of  the  world  is 
not  a  strict  hierarchy,  though  hierarchies  are  permitted  and  encouraged.  It  allows  for 
different  threads  of  control  as  well  as  a  combination  of  a  network  and  a  layered  structure. 
Ad  a  provides  several  kinds  of  program  units  that  aid  modularity,  namely,  subprograms, 
tasks,  packages,  and  generics. 

Subprograms  may  be  either  procedures  or  functions.  They  are  similar  to  subroutines 
in  other  languages.  A  task  is  similar  to  a  subprogram  except  it  provides  separate  parallel 
threads  of  control,  often  needed  in  real-time  or  concurrent  processing.  Packages  are  the 
basic  unit  for  structuring  programs.  A  package  is  usually  a  grouping  of  similar  program 
elements  that  may  be  used  by  other  parts  of  the  program.  For  example,  a  package  mav 
contain  procedures,  functions,  type  declarations,  exception  declarations,  and  tasks.  A 
generic  unit  can  either  be  a  package  or  a  subprogram.  A  generic  unit  is  a  template  from 
which  a  non  generic  unit  can  be  obtained. 

Ada  is  richer  in  programming  structure  constructs  than  other  languages,  which 
results  in  a  great  degree  of  control  over  the  program  name  space*’,  more  manageable 
parallel  software  development,  and  also  a  reduction  in  the  "ripple  effect"  of  errors.  It 
is  generally  thought  that  better  structured  code  leads  to  better  quality  code,  because 
it  is  easier  to  read  and  maintain.  The  existence  of  the  different  kinds  of  program  units 
makes  it  important,  to  master  new  structuring  techniques  and  the  interrelationships  of 
t  lie  units. 

There  are  some  similarities  and  also  some  fundamental  differences  between  the 
classes  of  program  units.  The  similarities  are  that  each  have  a  specification  and  a  bodg. 

I  he  specification  satisfies  a  “need  to  know"  on  the  caller’s  behalf.  It  defines  t  he  interface 
to  the  other  program  units.  In  Ada,  the  information  needed  to  call  another  unit  is 
intentionally  isolated  from  the  implementation  of  that  unit.  The  purpose  is  to  minimize 
"coupling"  and  increase  the  independence  of  the  units.  The  theory  behind  it  is  to  force 
the  programmer  to  think  in  terms  of  the  calling  interfaces.  The  body  contains  the 
implementation. 

2  Program  name  space  refers  to  the  set  of  names  of  program  entities  (variables,  procedures,  exception 
etc  )  which  are  accessible  (can  be  named)  from  a  particular  point  in  the  program  execution  Modern 
software  engineering  practices  encourage  restricting  the  name  space  in  order  to  isolate  the  effect  of 
program  changes. 
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Packages  are  a  relatively  new  concept;  from  a  structure  point  of  view,  packages 
permit  an  easy  way  to  split  a  program  into  smaller,  understandable  units.  Packages 
promote  maintainability  by  localizing  changes,  restricting  the  impact  of  a  change.  This 
makes  maintenance  easier  because  as  long  as  the  interface  (the  package  specification) 
does  not  change,  no  other  programs  are  affected  by  a  modification  to  the  corresponding 
package  body. 

The  ability  to  import  a  package  is  distinct  from  the  capability  to  include  a  file 
containing  data  and  other  routines.  In  other  languages,  include  files  are  generally  just 
textual  expansions  at  the  specified  location.  In  Ada  however,  packages  provide  a  much 
more  selective  mechanism  because  you  bring  in  only  the  specification,  although  the  body 
of  course  will  be  automatically  brought  in  so  that  the  executable  code  is  available  at  run¬ 
time.  Unlike  traditional  include  files,  packages  provide  the  user  with  a  very  fine  degree 
of  control  over  what  data 'functions  are  known  and  callable;  mainly  because  a  package 
can  be  imported  deep  in  the  hierarchy  of  the  program,  so  that  higher-level  modules  are 
unaware  of  it.  It  can  be  difficult  to  understand  the  static  nature  of  packages.  They 
are  containers  rather  then  executable  units,  yet  the  compiler  generates  code  for  them. 
Unlike  traditional  units,  packages  are  not  directly  callable  entities,  though  by  importing 
them  one  can  call  those  entities  defined  in  the  package  specification. 

One  of  the  hard  things  to  learn  about  designing  in  Ada  is  how  to  allocate  declara¬ 
tions  and  code  into  different  packages.  Because  packages  are  such  a  basic,  fundamental 
unit,  the  software  allocation  to  different  packages  is  effectively  the  program  design.  The 
software  should  be  allocated  to  minimize  dependencies  between  packages,  partly  to  limit 
recompilation  when  modifying  package  specifications. 

22.1.2  Separate  Compilation 

Generally,  separate  component  compilation  in  other  languages  is  best  described  as 
being  independent  from  other  component  compilations  because  there  is  no  cross  checking 
and  external  references  are  generated  for  entities  not  self-coni ained.  However,  Ada 
with  a  program  library,  provides  separate  compilation  where  each  component's  external 
references  are  checked  against  the  component  containing  the  references  in  the  library. 
This  separate  compilation  is  further  enhanced  by  having  the  specification  and  body  of 
a  component  as  individually  compilable  library  units.  The  implication  is  that  after  the 
high-level  design  establishes  some  top-level  packages,  the  software  development  of  the 
modules  can  then  proceed  largely  in  parallel.  Separately  compilable  units  (of  wrhich 
library  units  are  a  subset)  include  package  specifications,  packages  bodies,  procedures, 
functions,  generic  units,  and  task  bodies.  Ada  includes  a  mechanism  to  break  out  smaller, 
separately  compilable  units  from  a  larger  enclosing  one. 

The  specifications  can  be  compiled  separately  to  check  the  validity  of  the  interfaces. 


22-3 


I 


As  a  result,  Ada  identifies  errors  during  the  design,  which  is  less  costly  than  discovering 
and  correcting  errors  in  the  integration  or  testing  phase. 

The  compilation  of  any  separately  compiled  unit  may  depend  on  multiple  program 
units.  The  significance  of  this  lies  with  the  ability  to  control  the  name  space.  Rather 
than  import  (include)  a  program  unit  at  the  top  level  of  the  hierarchy,  it  can  be  imported 
such  that  it  is  only  known  to  a  low-level  subunit. 

Other  languages,  such  as  C,  provide  independent  compilation  of  modules  which  are 
compilable  in  any  order.  Independent  compilation  produces  external  references,  without 
performing  the  static  (compile-time)  interface  checking  that  separate  compilation  in  Ada 
does.  Because  of  the  static  interface  checking  between  the  component  being  compiled 
and  the  components  in  the  library,  the  programmer  must  pay  attention  to  the  order  in 
which  he  compiles  the  modules,  although  this  is  enforced  by  the  compiler  and/or  linker. 
The  static  interface  checking  forces  the  programmer  to  validate  the  design  specifications 
before  proceeding  with  the  package  body. 

22.1.3  Abstraction 

Ada  allows  for  the  abstraction  of  data  and  algorithms.  Features  permit  both  data 
and  process  encapsulation. 

Ada  is  a  strongly  typed  language.  All  objects  must  be  declared  and  have  a  specific 
type.  As  in  other  languages,  there  are  predefined  types.  Ada  also  allows  the  user  to  define 
new  types.  Lser-defined  types  can  have  specific  ranges  and  specified  accuracy  values. 
Being  able  to  define  the  range  of  a  type  allows  the  user  to  specify  design  constraints. 
For  example,  a  body  temperature  thermometer  could  be  represented  by  a  real  number 
type  from  85.0  to  110.0  with  increments  of  0.1.  An  advantage  of  strong  typing  is  that 
some  errors  in  passing  parameters  and  in  performing  comparisons  and  computations  are 
identified  at  compile  time,  rather  than  during  execution.  One  of  the  potential  pitfalls  of 
strong  typing  is  for  a  user  to  define  too  many  numeric  types  and  then  need  to  perform 
type  conversions  to  be  able  to  perform  operations  on  values  in  the  different  types.  This 
can  be  avoided  by  creating  a  few  basic  numeric  types  and  then  using  these  types  as  the 
base  for  user-defined  subtypes,  enabling  direct  comparisons.  A  good  up  front  design 
could  avoid  these  problems. 

I  nderstanding  types  in  Ada  may  be  difficult  for  programmers  coming  from  a  FOR¬ 
TRAN  or  assembler  background.  It  is  likely  that  there  will  be  confusion  between  types 
and  objects  in  the  beginning.  Furthermore,  programmers  may  have  trouble  with  the 
concept  of  naming  a  value,  as  used  in  declaring  enumeration  types. 

Packages  allow  the  user  to  define  abstract  data  types,  one  of  the  foundations  of 
object-oriented  programming.  All  of  the  data  in  the  specification  will  be  visible  to  a 
program  that  uses  the  package.  A  package  specification  can  include  the  type  declarations 


22-4 


for  the  variables  used  in  the  package,  the  names  and  parameters  of  the  procedures  and 
functions  contained  in  the  package,  the  exceptions  that  are  defined  in  the  package,  other 
packages  and  tasks. 

Besides  controlling  the  scope  by  grouping  all  of  the  declarations  together  in  a  pack¬ 
age  specification,  the  programmer  can  extend  the  level  of  abstraction  by  “hiding”  the 
definition  of  a  type  from  a  calling  program  by  declaring  it  a  private  type.  This  class  of 
declaration  imposes  restrictions  on  the  use  of  the  type.  Although  a  programmer  want¬ 
ing  to  use  the  package  can  "see”  the  private  type  declaration,  his  code  cannot  “use” 
the  information  in  this  declaration.  This  is  advantageous  because  if  the  calling  program 
doesn't  know  how  the  type  is  defined  and  cannot  see  how  the  related  subprograms  are 
implemented,  then  the  code  cannot  be  based  on  an  implementation  detail.  This  is  an 
advantage  because,  later,  if  the  implementation  in  the  package  is  changed,  the  calling 
program  will  still  be  valid3. 

Packages  support  an  abstraction  by  grouping  related  subprograms.  The  package 
body  has  the  full  code  for  procedure,  function  bodies  and  other  information  that  the 
caller  of  the  package  entities  does  not  need  to  know  about.  Often  packages  contain  all 
the  possible  operations  for  a  specific  type.  The  users  of  the  package  do  not  know  how  the 
package  is  implemented',  so  they  can  not  make  decisions  based  on  the  implementation. 

The  Ada  language  permits  the  overloading  of  subprograms.  Overloading  is  when 
two  or  more  distinct  subprograms  are  identified  by  the  same  name5.  This  means  that 
the  naming  of  routines  is  much  more  flexible  and,  hence,  procedure  and  function  names 
are  often  more  easily  understood.  Ada  also  allows  the  overloading  of  enumeration  lit¬ 
erals.  Overloading  is  a  new  name  for  a  concept  that  has  existed  to  a  degree  in  other 
languages.  However,  overloads  in  other  languages  have  been  system  defined,  rather  than 
user-defined.  I/O  and  numeric  facilities  have  always  had  the  same  name  or  symbol, 
regardless  of  the  parameter  type.  An  example  is  A  +  B.  If  the  parameters  A  and  B  are 
numeric  then  addition  is  performed.  However  if  A  and  B  are  strings  then  concatenation 
is  performed. 

Overloading  is  useful  when  a  user  has  subprograms,  either  functions  or  procedures, 

3The  calling  program  may  need  to  be  recompiled  (a  disadvantage),  but  it  will  not  need  to  be  modified 
(a  greater  advantage). 

4Users  here  refer  to  the  scope  of  the  program  unit  importing  the  package.  The  programmer  can,  in 
all  likelihood  print  out  the  source  file  for  the  package  body.  The  point  is  that  he  may  only  write  code 
which  depends  on  the  package  specification  and  which  can  reference  entities  named  in  the  specification 
but  not  entities  declared  in  the  body  This  is  a  source  of  confusion  for  Ada  novices  because  they  will 
find  subprogram  declaration?  both  in  the  specification  and  the  body.  More  subprograms  are  often 
declared  in  the  body  than  in  the  specification  for  reasons  of  modularity  and  readability:  these  “hidden” 
subprograms  encapsulate  parts  of  the  algorithm  needed  to  implement  the  subprograms  declared  in  the 
specification. 

5It  should  be  noted  that  package  names  cannot  be  overloaded.  Variables  in  two  different  packages 
may,  however,  have  the  same  name  because  they  exist  in  different  name  spaces. 
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that  perform  similar  actions  but  on  different  types.  For  instance,  it  is  common  to  have  a 
sort  routine  for  several  different  types,  such  as  integers  and  floating  point.  Overloading 
permits  both  of  the  routines  to  be  called  “Sort”,  instead  of  Sort  .Ini  and  Sort  .Float. 
However  there  are  limits  to  overloading,  the  compiler  must  be  able  to  determine  which 
subprogram  to  use. 

Predefined  operators  in  Ada  can  also  be  overloaded.  This  is  good  when  the  user 
defines  a  new  type  and  wants  to  use  the  commonly  recognized  operators,  such  as  addition 
and  multiplication.  This  provides  a  very  powerful  facility  for  common  numeric  constructs 
based  on  matrices  and  vectors.  A  function  which  overloads  a  predefined  operator  may 
be  called  using  either  infix  notation  or  the  regular  function  call  notation.  Being  able  to 
use  overloaded  operators  with  infix  notation  increases  readability. 

22.1.4  Structured  Control 

Ada  provides  statements  to  handle  program  flow  control,  real-time  actions,  and 
exceptions.  There  are  many  statements  in  Ada  that  are  similar  to  statements  in  other 
languages.  Many  of  them  have  stricter  rules  associated  with  them  to  increase  program 
logic  control  and  increase  compile-time  detection  of  errors. 

Consider,  for  example,  the  case  statement.  Every  possible  value  of  an  object  in  a 
case  statement  must  be  provided  an  option  or  a  semantic  error  will  be  flagged  during 
compilation.  The  others  clause  can  be  used  to  cover  any  value  that  is  not  explicitly 
provided  an  option. 

The  goto  statement  is  allowed  in  Ada.  although  use  of  it  is  strongly  discouraged. 
Inappropriate  use  of  a  goto  in  Ada.  will  raise  errors  upon  compilation. 

Tasks  permit  a  user  to  execute  programs  simultaneously.  Tasks  provide  a  user  with 
parallel  threads  of  control.  With  multiprocessors  they  may  provide  actual  concurrencv, 
and  apparent  concurrency  with  a  single  processor.  The  tasks  can  communicate  with 
each  other,  and  wait  for  each  other  when  necessary.  Through  task  rendezvous.  Ada 
provides  a  mechanism  for  synchronization  and  data  transmission. 

Ada  provides  ways  to  resolve  unexpected  situations,  which  increases  the  reliability 
of  the  system.  In  Ada  these  exceptional  occurrences  are  referred  to  as  exceptions.  Ex¬ 
ceptions  stop  the  sequential  execution  and  pass  the  control  to  a  different  location  in  the 
program.  Exceptions  can  be  used  as  a  mechanism  to  support  a  fault-tolerant  system. 
Statements  to  rectify  an  unexpected  situation  are  located  at  the  end  of  program  blocks. 
These  statements  are  called  exception  handlers.  Exception  handlers  can  solve  the  prob¬ 
lem,  pass  the  exception  to  a  higher  level  (i.e.,  the  calling  routine)  or  do  both.  If  an 
exception  remains  unresolved,  is  propagated  to  the  main  program  and  is  not  resolved  in 
the  main  program,  then  execution  of  the  program  is  terminated.  Within  exception  han¬ 
dlers,  messages  can  be  displayed,  errors  can  be  resolved,  and  files  can  be  closed  to  permit 
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clean  exiting  of  the  program.  There  are  several  predefined  exceptions.  For  example,  one 
would  be  raised  upon  an  attempt  to  perform  an  operation  with  a  zero  divisor.  Users 
can  also  define  and  raise  their  own  exceptions.  One  of  the  advantages  of  user-defined 
exceptions  is  to  give  the  programmer  control  over  the  granularity  of  exceptions. 

In  a  very  loose  fashion,  the  exception  facility  is  analogous  to  a  very  structured 
goto  to  the  extent  that  when  an  exception  is  raised,  control  flow  must  be  transferred 
to  the  exception  handler  at  the  end  of  the  current  program  block  or  to  a  higher  level. 
Moreover  at  the  end  of  the  handler,  control  must  be  transferred  immediately  outside  the 
block  of  the  handler.  In  general,  predefined  exceptions  should  not  be  raised  explicitly 
by  a  programmer  because  there  is  no  guarantee  that  the  exception  was  caused  by  the 
programmer-specified  condition  rather  than  some  other  unforeseen  run-time  violation. 

In  developing  packages,  the  designer  should  think  carefully  about  what  error  con¬ 
ditions  might  occur  (such  as  stack  overflow,  validation  failure)  and  whether  or  not  he 
should  name  these  conditions  (i.e..  declare  exceptions)  to  allow  programs  using  this 
package  to  trap  for  this  exception  and  choose  their  most  appropriate  course  of  action. 
A  detailed  discussion  of  exception  usage  is  found  in  ADA85  . 

22.1.5  Reusability 

Usually  reusable  components  are  self  contained  units,  that  are  easily  transferable  to 
other  programs.  Packages  are  good  for  grouping  related  subprograms.  Often  a  package 
will  contain  all  of  the  subprograms  for  a  user-defined  type. 

Another  aspect  of  Ada  that  supports  reusability  is  a  generic  unit.  A  generic  unit 
is  a  template  of  either  a  package  or  subprogram,  from  which  a  non  generic  unit  can  be 
obtained.  They  are  best  used  for  programs  units  which  replicate  a  single  algorithm  for 
several  different  types  of  data.  An  example  for  a  generic  package  would  be  a  sort  routine. 
The  same  basic  program  could  be  used  for  integers  and  reals.  So  to  use  the  routine,  a 
copy  of  the  generic  unit  is  generated  for  the  specific  type  to  be  used  with  the  program. 
Generics  need  not  be  found  only  at  the  utility  routine  level.  The  top-level  design  for  a 
subsystem  could  be  written  as  a  set  of  generic  packages. 


22.1.6  Environment  specific  features 

Motivated  bv  the  needs  of  the  embedded  systems  community,  the  Ada  features 
machine  code  insertions  and  pragma  interface,  provide  ways  to  interface  with  other 
high  order  languages,  assembly  language,  machine-specific  language,  and  the  underlying 
hardware.  Interfacing  with  other  software,  such  as  databases,  is  discussed  in  Edition  3, 
Section  20. 

In  Ada.  the  compiler  determines  where  the  code  will  be  stored,  how  types  and 
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objects  will  be  represented  and  stored,  etc.  Representation  clauses  and  representation 
pragmas  permit  the  user  to  vary  this.  Representation  clauses  work  with  four  types  of 
clauses:  length  clauses,  enumeration  clauses,  record  representation  clauses,  and  address 
clauses. 

The  length  clause  is  used  to  specify  the  amount  of  memory  the  compiler  should  use 
in  representing  objects  of  a  type.  The  enumeration  representation  clause  permits  the 
user  to  specify  the  internal  codes  for  an  enumeration  type  literal.  The  internal  codes 
specified  do  not  have  to  be  consecutive,  though  gaps  can  cause  operations  like  finding  the 
succeeding  value  to  be  less  efficient.  The  record  representation  clause  allows  the  user  to 
specify  the  bit-by-bit  layout  of  each  component  of  a  record  to  be  specified.  The  address 
clause  permits  the  user  to  specify  the  storage  address  of  an  object,  subprogram,  package, 
or  task.  It  can  also  associate  a  hardware  interrupt  with  a  task  entry.  This  clause  is 
useful  in  embedded  applications  where  the  memory  location  of  called  subprograms  must 
be  known. 

The  interaction  between  the  representation  specifications  and  the  use  of  other  lan¬ 
guage  features  can  create  some  difficult  cases  for  the  compiler  that  ran  potentially  result 
in  inefficient  code.  Good  practice  would  be  to  isolate  the  representation  specification 
items  in  a  package  body,  and  provide  an  interface  (i.e.,  the  bit  handling  operations) 
through  the  package  specification. 

22.2  Programming  Style 

Unlike  COBOL  and  some  other  languages.  Ada  is  free  format.  There  are  no  line 
numbers,  and  statements  may  start  in  any  column.  Therefore  the  programming  style 
for  Ada  is  left  up  to  the  user.  DoD-STD-2167A  has  an  appendix  for  programming  style 
that  contractors  should  default  to.  or  use  as  the  basis  for  defining  their  own. 

The  most  important  point  to  make  about  programming  style  for  Ada  is  that  the 
programming  style  chosen  should  be  consistent.  Among  other  goals,  the  Ada  language 
was  designed  to  be  reusable  and  maintainable,  both  of  which  require  that  a  person 
unfamiliar  with  a  program  be  able  to  pick  it  up  and  understand  what  is  being  done. 

A  project  must  establish  coding  standards  and  styles  right  from  the  beginning.  It 
is  especially  important  to  establish  the  standards  early  in  the  life  cycle  if  the  design 
is  being  done  in  Ada.  Written  standards  allow  Quality  Assurance  1o  have  an  explicit 
domain  to  check. 

Programming  style  is  characterized  by  the  format  of  the  code  and  the  naming 
conventions  used.  Both  aspects  are  discussed  in  the  following  subsections,  as  well  as  the 
types  of  tools  which  support  good  programming  style. 
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22.2.1  Style  Attributes 

Programmers  accustomed  to  other  languages  might  have  problems  adjusting  to 
Ada’s  free  format  aspect,  i.e.,  there  is  unlearning  and  relearning  that  needs  to  be  done. 
Considering  that  Ada  is  basically  free  format,  some  programmers  may  complain  about 
having  to  follow  certain  conventions,  but  it  is  important  because  style  has  a  direct 
relation  to  readability.  Also  with  the  increasing  availability  of  syntax-directed  editors 
and  other  tools,  there  is  no  reason  for  not  having  properly  and  consistently  styled  code. 

There  are  some  generally  accepted  programming  conventions.  These  are: 

•  Provide  a  structured  header  comment, 

•  Indent  nested  structures, 

•  Differentiate  reserved  words  from  program  variables  with  the  use  of  upper  and 
lower  case  letters. 

•  I'se  whitespace  (blank  lines)  to  enhance  readability. 

•  Cse  variable  names  that  are  self-explanatory,  and 

•  I  se  comments  to  increase  underst andability  only  where  necessary. 

Figures  1  and  2  show  an  example  program  which  follows  the  general  conventions 
listed  above,  augmented  by  the  following: 

•  Reserved  words  appear  in  lower  case  letters, 

•  The  first  letter  of  each  non  reserved  word  is  capitalized,  except  for  prepositions, 

•  TO”  in  10  package  names  is  capitalized  n  general,  abbreviations  are  capitalized. 

•  In  a  subprogram  structure,  the  following  words  are  aligned: 

-  with, 

-  procedure  (or  function). 

-  begin, 

-  end, 

•  The  subprogram  name  is  repeated  after  the  word  “end”  and  is  included  as  a  com¬ 
ment  after  the  word  “begin”,  and 
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— //  AORUt  Jane  Doe  February  12,  1986 

— // 

— //  ration:  Insert  a  n in  and  corresponding  telephone  number  in 
— //  the  directory. 

— // 

— //  err aum.  pkogbam  unotnacs: 

— // 

— //  Vlad  —  procedure  which  locates  an  entry  in  the  directory. 

— //  Sawe_Di rectory  —  procedure  which  stores  directory  in  a  file. 

— //  Directory  —  global  data  structure  of  directory  information 

— //  records . 

—//  Haximua_Slze  —  eaxiaum  number  of  records  that  can  be  stored 
— *//  in  the  directory. 

— //  Current_Size  —  current  nuaAer  of  records  contained  in  the 

—//  directory. 

— //  Name_Type  —  type  for  representing  the  name  entry  in  directory 

— //  records. 

— //  Telepbone_ttaaber_Type  —  type  for  representing  the  telephone 

— //  number  entry  in  the  directory  records. 

— //  lodes  Type  —  subtype  for  representing  indices  into  the  directory. 

— // 

— //  BOIIIB  OBITS: 

— // 

— //  None . 

seperata(Dlrectory_Nanager ) 

procedure  Insert  (Name  :  in  Name_Type; 

Telephone Jtumber  :  in  Telephone_Number  JType; 

Duplicate? resent  :  in  out  Boolean; 

3pace_A*aIlable  :  in  out  Boolean)  is 

Entry_Uacat ion  :  Indez_Type; 

begin  —  Insert 

—  check  to  see  if  room  exists  for  additional  entry 
Spece_Available  :■  Current_3ize  <  Mazimua_Size; 

Find  (Name,  Entry_Location,  Dupl icate_Present ) : 

if  not  Duplicate_?resent  then 

if  Space_Available  then  —  add  entry 

Current_Length  :*  Current_C,ength  *  l: 

Oirectory(Current_Length ) . tiaeM  :*  Name; 

Directory ( Cur  rent _Length ). TelapnoneNusOer  :*  TelephoneMuaber 


end  i f : 

end  if: 


SeweJJirectory; 
end  Insert; 


Figure  1:  Example  of  coding  style 
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— // 

— //  nUOUi  Inaect  a  ojm  and  correapondlng  telephone  nunbac  In 
— //  the  directory. 

— //  _  _  _ 

— //  r* 

— //  procedure  which  loeacaa  an  entry  In  tba  directory. 

— //  a*v«_otm*CTO«i 

— //  procedure  which  storea  dicaetocy  in  a  file. 

— //  a anew 

— //  global  daea  aeructuca  of  dlractocy  information  racotda. 

— //  WUZMDM.SIZS 

— //  aanlnaa  nunber  of  cacocda  that  can  ba  atocad  In  tha  dicaetocy. 

— //  cotinrr_3tz* 

-'//  currant  nunbac  of  cacocda  eontalnad  In  tha  dicaetocy. 

— //  HAMjrrra 

— //  type  foe  rapreaentinq  tha  naaa  antcy  in  dicaetocy  cacocda. 

— //  TKLZPSD«_!IOm**jrT?S 

— //  typa  for  repreaaatinq  tha  talaphona  nunbac  antcy  in  tha 

— //  dicaetocy  raeoeda. 

— //  nmajrrw 

—//  aubeype  for  cepreaentinq  indlcaa  into  tha  dicaetocy. 

— //  _ 

— / /  ffBTTCwtdd  UWITS : 

— //  bona. 

aaparaca  <  OIUCTOR.HMMCa ) 
procaduca  IHBOT 

|M  :  in  HAM_TY»t: 

telepeowjhmbo  :  m  rELXPaant number  _rr?t ; 

ooPLiCAn_ranurr  :  in  out  boolsae; 

3VAC2  AVAILABLE  :  in  out  «r)OMHUI 

)  ia 

array _locatioh  :  ina.Tm,' 
begin  — *  rnsarr 

—  cnaeh  to  aaa  if  cooa  aalata  foe  additional  antcy 
SPACE  _  AVAILABLE  :*  CBB»Urr_SIZ*  <  NAXIMON_SIZE; 

PIBD  (HAW. 

arrar^LOCATiOH. 

□oplicatE-PRESEbt 

) : 

if  not  OOPLICATEPRKSEWT 
chan 


if  SPACE  AVAILABLE 
chan  —  add  antcy 

CniBBET_LEBGTH  :  *  CUMOrT_LEMGTB  • 

DIRECTORY ( COIOUBrr_LatSra ) . MAW  :*  NAM; 

DIRECTORY  (CnRRERT~LSKCTB)  .  TELEPHOEl  _NOMBUl  ;•  tTLEPHOM  NUMBER 


and  i  f ; 
and  if; 

SAVR_DIRECTOBY: 


Figure  2:  Example  of  alternate  coding  style 
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•  If  all  elements  of  a  statement  cannot  fit  well  on  one  line,  they  are  continued  on  the 
next  line  and  are  aligned  so  that  they  are  easily  readable  (frequently  parameters 
in  a  subprogram  declaration  will  each  be  listed  on  a  separate:  line,  with  the  colons 
aligned). 

Other  programmers  follow  a  variation  of  these  guidelines,  depending  on  personal 
and  project  preference.  Some  of  the  frequent  differences  are  in: 

•  Capitalization  of  all  user  defined  identifiers, 

•  Varying  the  degree  of  indentation,  and 

•  Varying  the  alignment  of  control  structures. 


22.2.2  Naming  Conventions 

The  Ada  language  does  not  set  a  specified  length  for  identifiers,  though  most  im¬ 
plementations  limit  them  to  the  source  program's  line  length.  For  identifiers  that  are 
made  up  of  more  than  one  word,  an  underscore  is  frequently  used  between  the  words. 

Since  the  length  of  identifiers  is  only  limited  by  a  program’s  line  length,  abbreviating 
words  is  strongly  discouraged,  except  for  abbreviations  that  are  universally  understood  or 
used  project  wide.  There  are  two  frequently  used  methods  for  abbreviating  words.  The 
methods  are  dropping  the  vowels  from  the  word,  and  truncating  the  word.  Whichever 
method  is  used  it  should  be  fairly  consistent  for  the  project.  A  detailed  discussion  of 
naming  conventions  may  be  found  in  ADA85  . 

It  is  usually  easier  to  decipher  code  if  it  reads  like  English.  Effective  use  of  naming 
conventions  can  make  comments  unnecessary.  Some  naming  conventions  that  aid  in  this 
are: 


•  Objects  are  usually  named  with  nouns.  Boolean  objects  are  named  as  if  they  ask 
a  question. 

•  Procedures  are  named  with  verbs  to  denote  that  an  action  is  occurring,  and 

•  Functions  are  named  with  a  noun  or  a  conditional  clause  if  a  Boolean  result  is 
returned. 

Organizations  have  and  should  set  up  guidelines  for  naming  conventions.  For  in¬ 
stance.  in  addition  to  standard  program  layouts,  one  such  guide  prescribes  [FOF87  : 

•  Individual  suffixes  to  identify  data  type  names,  package  names  and  object  names, 
and 

•  The  use  of  full  names  when  referring  to  entities  inside  of  package  specifications. 
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22.2.3  Tools 


There  are  many  tools  available  through  vendors  to  aid  users  and  increase  program¬ 
mer  productivity.  Two  types  of  tools  designed  to  aid  users  in  writing  well  styled  code 
are  syntax-directed  editors  and  pretty  printers. 

Syntax-directed  editors  aid  programmers  by  automating  some  of  the  program  code 
entry.  This  can  be  accomplished  through  the  use  of  code  templates  and/or  keyboard 
macros.  Syntax-directed  editors  usually  fill  in  the  semi-colons  and  various  parts  of  Ada 
constructs.  The  editors  embody  the  syntax  rules  for  Ada.  The  user  can  spend  more 
energy  writing  the  code  and  less  on  the  proper  syntax.  Some  of  these  tools  also  provide 
a  way  to  pre  process  the  code  into  a  structured  format  and  to  check  for  errors. 

Several  programming  environments  provide  graphical  ways  to  design  the  system 
and  have  tools  that  automatically  generate  program  code.  (See  Edition  2,  Section  8.4 
for  a  discussion  of  some  specific  methods  and  tools.)  Some  systems  generate  frames 
(i.e..  the  general  layout  of  the  programs),  while  other  systems  produce  compilable  code. 
Often  the  user  will  then  use  an  editor,  such  as  a  syntax-directed  editor,  to  complete 
what  has  been  generated  from  the  graphical  design  by  filling  in  type  declarations  and 
other  details.  Some  of  these  tools  also  tie  directly  into  document  generators,  so  that 
there  is  a  way  to  maintain  consistency  between  specifications  and  code. 

Pretty  Printers  format  source  code  so  that  it  is  more  readable.  They  ensure  the 
uniformity  of  code  style  and  format.  Some  pretty  printers  will  accept  user-defined  format 
specifications. 

Tools  are  being  developed  rapidly  and  it  would  be  difficult  to  provide  a  complete 
list  of  all  vendor  offerings.  Vendors  exhibit  frequently  at  the  major  Ada  conferences, 
such  as:  SIC! Ada.  AdaJl  (I.  and  Ada  Expo. 


Section  23 

Policy  Updates 


The  signing  of  Department  of  Defense  (DoD)  Directives  3405.1  and  3405.2  man¬ 
dating  the  use  of  Ada  marks  a  policy  milestone.  All  the  services  must  now  write  an 
implementation  plan  consistent  with  these  directives,  modifying  or  creating  regulations 
as  needed  in  order  to  be  compliant  with  the  Ada  mandate.  The  Air  Force  regulations 
addressing  computer  resources  are  undergoing  revision  to  be  compliant  with  these  di¬ 
rectives. 

The  Ada  Joint  Program  Office  (AJPO)  remains  the  focal  point  for  Ada  technology. 
The  AJPO  is  responsible  for  the  validation  procedures,  as  discussed  in  Edition  ],  Section 
3.1.  \alidated  compilers  will  now  have  a  special  certification  stamp. 

23.1  DoD  Directive  Status 

Two  directives  requiring  the  use  of  Ada  in  all  DoD  software  were  signed  by  Deputy- 
Secretary  of  Defense  William  H.  Taft,  IV.  Directive  3405.1 .  dated  2  \pril  1987,  discusses 
computer  programming  language  policy  for  the  development  and  support  of  all  DoD 
software.  Directive  3405.2.  dated  30  March,  1987.  addresses  the  use  of  Ada  on  all 
mission  critical  software. 


23.1.1  Directive  3405.1 


Directive  3405.1  states  the  DoD  policy  that  Ada  is  required  both  for  mission  critical 
and  for  all  other  applications.  The  stated  goal  is  to  have  Ada  become  the  single,  common 
computer  language  for  all  defense  software.  Major  software  upgrades  must  also  be  done 
in  Ada.  Programs  already  in  full-scale  development  may  continue  to  use  a  language 
other  than  Ada  through  deployment  and  maintenance.  When  another  approved  higher 
order  language  is  more  cost-effective  over  the  application's  life  cycle,  this  language  may 
also  be  used  in  lieu  of  Ada. 

Approved  higher  order  languages  are: 


Ada 

C/ ATLAS 
COBOL 
CMS-2M 
CMS  2Y 
FORTRAN 


ANSI/M  IL-STD-1 81 5A- 1983  (FIPS  119) 

IEEE  STD  716-1985 
ANSI  X3. 23-1985  (FIPS  21-2) 

NAVSEA  0967LP-598-2210-1982 

NAVSEA  Manual  M-5049,  M-5045.  M-5044-1981 

ANSI  X3.9-1978  (FIPS  69-1) 
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JOVIAL  (J73) 

Minimal  BASIC 
Pascal 
SPL/1 

.National  Bureau  of  Standards  (NBS)  Special  Publication  500-117  provides  further  guid¬ 
ance  in  the  selection  of  an  appropriate  high  order  language.  Directive  3405.1  supersedes 
DoD  Instruction  5000.31  (“Interim  List  of  Approved  Higher  Order  Programming  Lan¬ 
guages  (HOL)”). 

Directive  3405.1  states  an  order  of  preference  for  software:  1)  Commercial-Off-The- 
Shelf  (COTS)  packages  and  advanced  software  technology:  2)  Ada-based  software  and 
tools:  and  3,  approved  standard  HOLs.  The  decision  of  which  type  of  software  to  be 
used  should  be  based  on  an  analysis  of  the  life  cycle  costs  and  the  impact  on  competition. 

Responsibilities  for  the  implementation  of  the  policy  outlined  in  3405.1  are  allocated 
both  to  the  Assistant  Secretary  of  Defense  (Comptroller)  (ASD(C))  and  to  the  Under 
Secretary  of  Defense  (Acquisition)  (USD(A)).  Both  the  ASD(C)  and  l'SD(A)  are  re¬ 
sponsible  for  the  insertion  of  modern  software  technology  in  automated  data  processing 
and  mission  critical  systems  respectively.  The  ASD(C)  should  define  research  areas  for 
information  system  needs  and  provide  these  topics  to  the  USD(A),  who  is  charged  with 
establishing  software  technology  research  programs.  The  USD(A)  is  also  tasked  with 
managing  the  Ada  program  and  the  maintenance  of  the  Ada  language.  Furthermore, 
the  head  of  each  DoD  component  is  charged  with  developing  an  implementation  plan  to 
address  the  issues  in  the  directive,  designating  a  language-control  agent,  implementing 
a  waiver  process  to  resolve  requests  for  non-approved  HOLs  and  establishing  evaluation, 
training,  and  education  programs  for  advanced  software  technologies. 

23.1.2  Directive  3405.2 

Directive  3405.2  mandates  the  use  of  both  the  Ada  language  and  an  Ada-based 
program  design  language  (PDL),  preferably  a  compilable  one.  on  all  software  “integral  to 
weapon  systems.”  In  other  words,  all  mission  critical  computer  software  must  be  written 
in  Ada  and  compiled  by  a  validated  Ada  compiler.  Ada  is  the  preferred  language  for 
hardware  test  languages  for  Unit  Under  Test  equipment.  It  is  also  the  preferred  language 
for  unmodified  COTS  software  used  by  the  DoD.  The  use  of  DoD  STD-2167  and  DoD 
Handbook-28]  is  strongly  recommended;  the  software  engineering  principles  described 
therein  are  to  be  applied  to  the  production  of  defense  software. 

As  with  Directive  3405.1,  Ada  is  not  required  for  programs  which  are  already  in 
full-scale  development,  unless  the  software  is  undergoing  a  major  upgrade.  Directive 

3405.2  defines  a  major  upgrade  as  the  redesign  or  addition  of  more  than  one-third  the 


MIL-STD-1589C  (USAF) 

ANSI  X3. 60-1978  (FIPS  68-1) 
ANSI/IEEE  770X3.97-1983  (FIPS  109) 
SPL/1  Language  Reference  Manual, 
Intermetrics  Report  No.  172-1 
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soft  ware. 


The  l'SD(A)  is  tasked  with  coordinating  the  implementation  of  this  directive.  T  he 
heads  of  I)oD  components  must  develop  a  comprehensive  Ada  implementation  plan  that 
addresses  their  organization's  transition  plan  to  adopt  Ada.  for  example,  training  plans, 
regulations,  etc.  Furthermore,  each  D<d>  component  must  have  both  an  Ada  executive 
official  (focal  point)  to  monitor  Ada  programs  and  an  Ada  waiver  control  officer. 

Directive  3-105.2  designates  the  A.JPO  as  the  controlling  agent  of  the  MIL  STD  Ada 
(See  Edition  3.  Section  15).  1  he  Air  Force  is  responsible  for  providing  the  Ada  validation 
facility. 


23.1.3  Impact  of  these  Directives 

There  are  several  significant  points  to  he  made  about  the  two  directives.  Most 
significant  is  the  scope  of  the  \da  mandate:  it  encompasses  all  DoD  software,  not 
just  mission  critical  software.  I  he  earlier  DeLauer  memorandum  had  addressed  just 
software  integral  to  weapons  systems.  I  he  two  directives  reinforce  the  idea  that  Ada  is  a 
general  purpose  language  and  that  all  Pol)  programs,  including  management  information 
systems  (MIS),  for  example,  will  benefit  from  the  use  of  advanced  software  technology. 
1’lie  effect  will  be  to  gain  much  greater  computer  standardization  than  if  weapon  and 
support  systems  alone  were  required  to  use  Ada.  1  lie'  fact  that  the  directive  specifies 
Ada  for  all  other  applications  reflects  the  feeling  on  DoD's  part  that  the  technology  to 
support  Ada  both  exists  and  is  maturing. 

The  existence  of  these  two  directives  gives  industry  a  clear  signal  that  the  DoD  is 
committed  to  Ada.  For  some  time,  industry  had  felt  such  a  direction  was  lacking  and 
did  not  have  the  incentive  to  invest  heavily  in  Ada  software  engineering  tools,  training, 
or  research.  Several  recent  studies  AFC87  and  PSH87  had  noted  the  lack  of  a  directive 
and  strongly  urged  the  DoD  to  unite  behind  a  strong  policy  statement.  The  signing  of 
Directives  3105.1  and  3105.2  shows  that  DoD  is  serious  and  that  the  transition  to  Ada 
will  become  effective. 

Waiver  granting  authority  is  delegated  to  each  DoD  component.  Either  the  USI)(  A) 
or  the  ASD(C).  however,  may  request  to  review  waivers,  as  appropriate.  Thus  any 
component  granting  too  many  waivers  will  certainly  attract  attention  at  high  levels 
within  the  DoD.  Moreover,  waivers  cannot  be  granted  for  entire  programs;  waivers  can 
only  be  requested  and  issued  at  the  system  or  subsystem  level. 

T  he  fad  that  a  DoD  wide  directive  has  been  signed  will  enable  DoD  components 
to  issue  enforceable  regulations.  1  nlike  the  1  9S3  policy  letter  and  the  Draft  5000.31 
regulation.  Directives  3405.1  and  3405.2  are  official  and  1  heir  guidance  must  be  followed. 
Their  status  as  Directives  gives  them  more  prominence  and  is  evidence  that  ihe  DoD 
is  committed  to  language  standardization.  Ihe  fact  that  both  directives  are  effective 
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immediately  reemphasizes  this  point. 


23.2  Air  Force  Policies 

Current  Air  Force  policy  requires  the  use  of  Ada  or  JOVIAL  or.  all  major  programs. 
Only  validated  compilers  may  be  used.  This  policy  is  set  forth  in  Air  Force  Regulation 
(AFR)  800- 14,  which  must  undergo  revision  in  order  to  be  compliant  with  Directives 
3405. 1  and  3405.2.  At  the  time  of  this  writing,  t  he  Air  Force  is  still  working  on  submitting 
its  implementation  plan  to  the  AJPO. 


23.2.1  AFR  800-14 

As  noted  above,  AFR  800-14  does  address  Ada.  It  will  require  several  changes  in 
order  to  be  fully  compliant  with  Directives  3405.1  and  3405.2.  The  essence  of  these 
changes  follows: 

•  the  Ada  requirement  is  effective  immediately  for  all  programs,  not  just  major 
programs. 

•  an  Ada  based  FDL  requirement  must  be  added,  and 

•  the  waiver  policy  for  both  weapons  systems  and  information  systems  must  be 
defined  and  agreed  upon  among  Air  Force  components. 

Air  Force  Logistics  Command  (AFLC)  and  Air  Force  Systems  Command  (AFSC) 
jointly  issued  a  supplement  to  AFR  800-14  in  September  1987,  to  address  the  life  cycle 
management  of  computer  resources  in  systems.  This  supplement  mandates  the  use  of 
Ada  on  all  new  AFSC  and  AFLC  programs,  except  for  automatic  test  equipment  test 
programs.  Moreover,  major  programs  must  use  an  Ada-based  PDL.  Software  develop¬ 
ment  and  support  must  comply  with  DoD-STD-2167. 

The  AFR  800-14  Supplement  provides  a  framework  for  technology  transition.  Each 
Product  Division  (within  AFSC)  and  Center  (within  AFLC)  must  establish  a  Mission 
Critical  Computer  Resource  Focal  Point  (MCCRFP).  The  MCCRL  Ps  are  responsible  for 
the  distribution  of  information  (policy  and  technology  related)  and  for  the  tracking  and 
initial  processing  of  waivers.  The  AFR  800-14  supplement  provides  detailed  information 
on  the  content  of  waiver  requests  and  the  kinds  of  justification  material  required. 

23.2.2  AFR  700-9 

AFR  700-9,  which  is  currently  under  revision,  addresses  computer  programming 
language  policy.  It  is  expected  to  set  the  standards  for  communication  and  computer 
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systems,  to  outline  the  responsibilities  of  major  commands,  set  the  policy  on  program¬ 
ming  languages,  list  the  currently  approved  languages,  and  address  the  use  of  4th  gener¬ 
ation  languages  (4GL)  and  specialized  languages.  The  revised  AFR  700-9  will  be  based 
on  Directive  3405.1. 

23.3  Policy  Changes  since  Previous  Editions 

The  AJPO  has  announced  that  it  will  not  renew  the  federal  registration  of  the  Ada 
trademark.  In  lieu  of  the  trademark,  the  AJPO  has  adopted  an  Ada  certification  mark 
to  show  that  a  compiler  is  validated  under  the  Ada  Compiler  Validation  Capability 
(ACYC)  suite.  It  was  felt  that  the  certification  mark,  which  like  the  trademark  has  a 
legal  definition  in  the  United  States  Code,  was  a  more  appropriate  means  to  protect 
the  integrity  of  the  Ada  language.  Vendors  should  use  the  certification  mark,  shown  in 
Figure  3.  on  literature  and  documentation  associated  with  a  validated  compiler. 


TMH  PHOOUCT  CONFOIIMS 
TO  AfniMfeSTTMIIM  AS 
OCTHUMMO  TM<  AJPO 

UNom  its  cumurr 
TtSTVMS  MOCBMUf  S 


Figure  3:  Ada  certification  mark 
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Section  24 

Benchmarks 


In  earlier  editions  of  the  Program  Office  Guide  to  Ada,  benchmarking  was  discussed 
with  regard  to  performance  evaluation  of  Ada  Compilers  (Edition  1,  Section  6)  and  to 
the  Ada  Compiler  Evaluation  Capability  (ACEC)  (Edition  2,  Section  13).  In  Section 
6.3.2  of  Edition  1.  Execution  Speed,  it  was  indicated  that  comparing  benchmarks  for 
Ada  to  those  for  other  languages  can  be  quite  deceiving  if  not  performed  properly.  In  this 
section,  we  will  review  some  of  the  existing  benchmarks  for  Ada  and  some  of  the  current 
studies  underway  which  will  help  managers  select  systems  with  the  aid  of  benchmarks. 


24.1  Purpose  and  Description 

Benchmarks  are  used  to  perform  experimentation  and  evaluation  of  various  ap¬ 
proaches  in  order  to  minimize  risks  to  a  project.  In  general  the  benchmarking  process 
BRAI  N88  will  include  the  following  series  of  steps: 

•  Identifying  critical  areas. 

•  Analyzing  alternative  approaches, 

•  Creating  and  conducting  experiments,  and 

•  Applying  the  experimental  results  to  the  decision  making  process. 

Benchmarks  are  being  applied  to  compilers.  There  exist  several  synthetic  benchmarks6 
which  are  commonly  used  by  compiler  vendors  to  supply  comparison  data.  Some  of  the 
more  common  ones  are  discussed  in  Section  24.2. 

At  times,  it  is  advantageous  for  an  organization  to  modify  existing  benchmarks  or 
create  application  specific  models  in  order  to  measure  an  Ada  system’s  performance  in  a 
world  that  approximates  the  target  environment.  This  might  entail  running  applications 
comparable  to  the  finished  product  to  determine  if  code  size  and  execution  speed  are 
sufficient.  The  Common  Ada  Missile  Package  (CAMP)  Armonics  (armament  electronics) 
Benchmarks,  which  will  be  discussed  in  Section  24.3.6,  are  an  example  of  application 
specific  benchmarks. 

6  A  synthetic  benchmark  is  a  test  written  specifically  for  the  purpose  of  collecting  benchmark  data. 
Synthetic  benchmarks  are  distinguished  from  natural  benchmarks,  which  are  usually  application  code 
adapted  for  the  purposes  of  measurement. 
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24.2  Major  Existing  Benchmarks 


Benchmark  tests  are  designed  to  measure  the  capabilities  of  a  computer  system.  The 
results  are  used  to  compare  different  computer  systems  and  to  determine  the  suitability 
of  a  computer  system  for  particular  tasks.  The  basic  output  produced  by  a  benchmark 
consists  of  the  time  required  to  perform  some  task.  A  common  technique  is  to  write  a 
program  that  performs  some  representative  activity  between  calls  to  a  system  timer. 

Some  benchmark  tests  are  designed  to  measure  the  performance  of  individual  fea¬ 
tures  while  others  combine  several  features  in  a  single  test.  This  second  type,  commonly 
known  as  a  composite  benchmark,  captures  the  interaction  of  features,  but  it  should  not 
be  construed  as  representative  of  real-time  applications.  In  tuning  a  system,  results  of 
the  first  kind  of  benchmark  can  be  extremely  useful.  Refer  to  Edition  1.  Section  6.3.2. 
for  more  information  on  benchmark  application  techniques. 

24.2.1  Performance  Issues  Working  Group  (PIWG) 

The  objective  of  Performance  Issues  Working  Group7  (PIWG)  is  to  provide  informa¬ 
tion  to  the  Ada  community  on  performance  issues  related  to  Ada.  PIWG  has  developed 
and  distributes  a  test  suite  consisting  of  performance  related  tests. 

Anyone  may  submit  a  performance  issue  specification  to  PIWG  in  which  one  re¬ 
quests  performance  measurements  of  special  interest.  The  point  of  contact  is: 

Jon  S.  Squire 

Westinghouse  Electric  Corporation 

P.O.  Box  746 

M/S  1615 

Baltimore.  MI)  21203 

(301)765-3748 

bench  markka  jpo.sei.cmu.edu 

The  PIWG  suite  resides  in  the  directory  'ftp/public/'piwg,  on  AJPO.SEI.CMU.EDU. 

24.2.2  University  of  Michigan 

The  University  of  Michigan  tests  CDV86;  evaluate  the  execution  speed  of  specific 
features  of  the  Ada  programming  language.  The  focus  is  on  the  features  from  the  Ada 
language  and  run-time  system  that  are  believed  to  be  important  for  real-time  perfor¬ 
mance.  They  address  the  issue  of  real-time  performance  measurement,  with  particular 

7PIWG  is  an  ACM  SIGAda  Working  Group. 
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regard  to  time  measurement  and  scheduling.  This  approach  isolates  relatively  small 
items  to  allow  comparisons  of  critical  interest  (e.g.,  rendezvous  versus  subroutine  call). 
These  tests  have  revealed  some  interesting  observations  about  the  effect  of  compiler  de¬ 
signs:  for  example,  certain  methods  used  to  do  certain  optimizations,  dynamic  storage 
and  exception  handling  affected  the  benchmark  results. 

24.2.3  Whetstone 

The  Whetstone  benchmark  Ci'W76  ,  one  of  the  older  benchmarks,  measures  the 
performance  of  floating-point  arithmetic.  It  was  originally  written  in  ALGOL  60  and 
subsequently  translated  to  FORTRAN.  The  benchmark  computations  are  based  on  the 
statistical  distribution  of  statements  from  data  collected  in  1970.  Programming  lan 
guages  have  changed  greatly  since  then,  with  the  introduction  of  modern  features  such 
as  record  and  pointer  types,  so  Whetstone  does  not  cover  all  of  the  features  of  Ada. 
However,  the  Whetstone  benchmark  is  rich  in  floating  point  calculations,  and  as  such 
is  useful  for  comparing  systems  when  the  major  concern  consists  of  the  performance  of 
scientific  calculations. 

24.2.4  Dhrystone 

While  the  Whetstone  benchmark  is  biased  towards  numerical  computing,  the  Dhry¬ 
stone  benchmark  concentrates  on  systems  programming.  The  benchmark  looks  at  the 
type  of  data  and  operations  performed.  The  Dhrystone  benchmark  WEI84  used  recent 
data  on  the  actual  use  of  programming  languages8.  As  a  consequence,  the  Dhrystone 
benchmark  mainly  measures  the  speed  of  non-floating  point  code. 

The  Dhrystone  benchmark  was  developed  in  Ada  with  three  guidelines:  1)  the  code 
should  follow  good  programming  practice;  2)  the  distribution  of  constructs  should  be 
weighted  in  favor  of  systems  programming  software;  and  3)  the  benchmark  should  be 
designed  so  versions  in  other  languages  would  be  possible  with  minimal  modifications. 
This  last  goal  was,  in  fact,  difficult  to  achieve  because  of  the  disparity  of  constructs  in 
the  spectrum  of  programming  languages  (e.g.,  FORTRAN  has  neither  access  nor  task 
types). 

Programming  languages  used  include  FORTRAN,  XPL,  PL/1.  SAL.  ALGOL  68.  Pascal,  and  Ada 
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24.3  Additional  Work 


24.3.1  Production  Quality  Ada  Compiler  Report 

The  Production  Quality  Ada  Compiler  Report  'HHM86  .  produced  by  The  Aero¬ 
space  Corporation  for  the  Spar;-  Division  of :  he  Air  Force  Systems  Command,  is  intended 
to  provide  guidelines  for  evaluating  and  selecting  Ada  compilers.  The  report  defines  dif¬ 
ferent  levels  of  quality  compilers  It  specifies  :  lie  minimum  requirements  for  a  compiler, 
and  then  continues  to  describe  the  qualities  of  a  more  ideal  compiler. 

The  evaluation  of  an  Ada  compiler  to  lie  production  quality  is  based  on  satisfying 
the  following  requirements: 

•  Performance. 

•  Compiler  capacity. 

•  Tser  interfac 

•  Kxt  ei  nai  t  <#o|>  i  ’,i  eri’.o  e 

•  Ada  language  . 

•  Quality  assurance  ami  reba  billy.  c. 

•  Documentation 

l  ie  above  requirements  apply  to  a  compleie  compiler  system  (i.e.,  ihe  compiler,  the 
Ada  library  manager,  linker  loader,  and  Ada  run  time  system  >.  Guidelines  are  given  to 
evaluate  the  production  quality  of  a  c<  mpiler  system.  The  guidelines  specify  particular 
capabilities  and  characteristics  of  production  quality  compiler  system. 

Requests  for  copies  of  the  report  should  be  made  to: 

Aerospace  Library 
Reports  Circulation 

(Ml  1D9) 

P.O.  Box  ‘>‘25)57 

Los  Angeles.  C  \  9(m()9 

Report  No.  LOR  mtsfi(f.9b2  <'U)  1  or  NTIS  AD  A  182 

I  be  report  includes  self  test  software  to  enable  readers  of  the  report  to  evaluate  the 
production  quality  characteristics  of  their  own  compilers. 
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An  effort  is  underway  to  apply  the  guidelines  developed  in  this  report  to  commer¬ 
cially  available  compilers.  Two  VAX9  hosted  compilers,  from  DFX'10  and  Telesoft.  were 
selected.  The  compilers  are  being  installed,  and  the  suite  of  tests  described  in  the  report 
is  being  run.  A  report  on  the  DEC  results  can  be  obtained  from  the  point  of  contact 
listed  below.  The  Telesoft  results,  as  well  as  a  revised  version  of  the  Production  Quality 
Ada  Compiler  Report  definition,  should  be  available  later  in  1988.  The  point  of  contact 
is: 


Lt  Kurt  Maschoff 

Space  Division 

SD  AI  R 

P.O.  Box  92960 

Los  Angeles,  CA  90009 

(213)  643  1279 

(AV)  833-1279 


24.3.2  SEI  Benchmarks  for  Embedded  Real-Time  Systems 

The  Ada  Embedded  Systems  Testbed  (AEST)  project  at  the  Software  Engineering 
Institute  (SEI)  is  studying  benchmarks  to  obtain  data  on  the  readiness  of  the  Ada  lan 
guage  and  Ada  tools  for  use  in  real-time  systems.  The  focus  of  the  project  is  on  run  time 
performance,  not  compiler  statistics.  Both  the  PIWG  and  University  of  Michigan  bench¬ 
marks  are  being  run  on  VAX  hosted.  Motorola  68020  targeted  compilers.  Additional 
target  systems  under  consideration  include  the  M1L-STD  -1750A  processor  and  the  U.S. 
Navy  standard  processors. 

A  survey  of  benchmarks  has  been  conducted.  DO.N87  .  Initial  work  in  running 
the  benchmarks  has  revealed  inherent  problems,  documented  in  ALT87  and  AVrYY87j. 
Wild  swings  in  numbers  have  been  reported  because  of  differences  between  System. Tick” 
and  clock  resolution.  Dual  loop  benchmarks  do  not  necessarily  remove  the  effect  of  clock 
imprecision.  Benchmark  tests  need  to  be  run  for  a  large  number  of  iterations  in  order  to 
determine  a  stable  result.  Paging  hardware,  even  on  a  bare  machine,  can  affect  timing 
results. 

An  important  conclusion  of  [  A  LX 8 7 ]  is  that  Ada  benchmarks  are  not  fully  trans¬ 
portable;  in  other  words,  the  tester  should  expect  to  modify  and  adjust  the  tests  for 
a  given  system.  Both  efficiency  and  performance  considerations  should  be  enumerated, 
for  example,  code  generation,  run-time  support,  tasking  overhead,  exception  handling 
overhead,  subprogram  overhead,  etc.  Moreover,  the  underlying  assumptions  about  the 

®VAX  is  a  trademark  of  the  Digital  Equipment  Corporation. 

10DEC  is  a  trademark  of  the  Digital  Equipment  Corporation. 

"The  precision  of  the  machine  clock,  i.e.,  the  duration  of  one  tick 
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measurement  goals  and  their  accuracy  must  be  examined  and  validated  in  order  to  obtain 
meaningful  benchmark  results. 

24. 3. S  Real-time,  Run-time  Environment  Studies 

The  purpose  of  the  Real-time  Run-time  Environment  Studies  is  to  investigate  the 
performance  impact  of  real-time  environments  through  the  execution  of  benchmarks  for 
all  features  of  the  language.  The  tests  are  implemented  in  Ada,  JOVIAL  and  FORTRAN 
in  order  to  allow  comparison  between  these  languages.  There  are  also  tools  to  facili 
tate  comparison  and  analysis  of  test  results.  This  effort  is  sponsored  by  the  Computer 
Resource  Management  Technology  Program,  (Program  Element  64740F),  ESD/AYS, 
Hanscom  Air  Force  Base.  MA. 

The  Real-time  Run  time  Environment  Studies  is  a  system  which  contains  test  rou¬ 
tines  to  execute  language  features  and  input/output.  The  focus  of  these  studies  is  to 
create  benchmarks  that  are  very  specific  to  individual  Ada  language  features,  in  other 
words,  to  address  the  question.  “How  good  is  Ada  relative  to  other  languages  with  re¬ 
spect  to  size,  speed,  etc."  on  a  feature  by-feature  basis.  The  test  suite  includes  some 
well  known  composite  benchmarks  such  as  Dhrystone  and  Whetstone. 

The  products  of  this  effort  are  a  test  set  and  an  accompanying  user’s  manual.  The 
test  set  is  known  as  the  Ada  Compiler  Performance  Suite  (ACPS).  The  initial  version 
is  planned  for  the  VAX.  with  versions  for  the  IBM  and  1750  processor  planned.  The 
current  test  suite  and  preliminary  user’s  manual  are  available  from: 

Rich  Kayfes 
Aerospace  Corporation 
(Ml/165) 

P.O.  Box  92957 

Los  Angeles,  CA  90009 

(213)  336-6092 

24.3.4  Ada  Run-Time  Environment  Working  Group  (ARTEWG) 

The  Implementation  Dependencies  Subgroup  of  the  Ada  Run-time  Environments 
Working  Group12  has  collected  information  on  run-time  compiler  dependencies.  The 
information  is  being  assembled  into  a  catalog  that  will  list  the  run-time  implementation 
dependencies  as  they  relate  to  the  Ada  Language  Reference  Manual.  The  catalog  will 
give  users  the  needed  information  on  how  the  various  Ada  features  are  implemented  by 
different  compilers.  It  will  provide  insight  on  how  applications  will  behave  at  run-time. 

>*ARTEWG  is  an  ACM  SIC.Ada  Working  Group 
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See  Section  28.4  for  further  information. 

24.3.5  Commercial  Ada  Users  Working  Group  (CAUWG) 

The  intent  of  the  Commercial  Ada  Users  Working  Group13  (CAUWG)  is  to  serve  as  a 
liaison  between  potential  commercial  Ada  users,  and  the  defense  community  and  AJPO. 
CAUWG  will  be  a  focal  point  for  the  exchange  of  information  on  the  Ada  transitional 
experience.  The  group  is  investigating  the  barriers  to  the  commercial  use  of  Ada  and 
identifying  ways  of  resolving  the  technological  gaps  uncovered.  Specifically,  CAUWG  is 
looking  into  Ada  interfact  issues  for 

•  fourth  generation  languages  (  lGl.s). 

• COHOL 

•  RPG2  systems. 

•  AUTOCODK. 

•  ISAM  VSAM  files,  and 

•  text  processing. 

CAl’WG  is  also  investigating  t  lie  kind  of  support  needed  for  the  use  of  Ada  in  distributed 
processing  applications. 

CAl’WG  will  document  the  results  of  its  activities  through  guidelines  on  Ada  prod 
ucts  and  tools,  tailored  for  the  needs  of  commercial  users.  I  he  point  of  contact  is: 

Dave  Dike! 

Addamax  Corporation 
7799  Leesburg  Pike.  Suite  900. 

Tysons  Corner.  \  A  22043 
(703)847-6755 


24.3.0  Armonics  Benchmarks 

Armonics,  short  for  armament  electronics,  software  is  one  of  the  part  categories 
developed  under  the  Common  Ada  Missile  Program  (CAMP).  The  software  has  been 
modified  to  be  suitable  as  benchmark  tests  for  evaluating  Ada  system  performance  in  this 
specific  domain.  Unlike  other  benchmark  efforts  which  tend  to  be  more  language-feature 
or  capacity  oriented,  these  tests  are  application  specific. 

I3CAL’WG  is  an  ACM  SIGAda  Working  Group. 
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There  are  two  series  of  tests:  one  for  missile  operational  parts  and  the  other  for 
support  routines.  An  example  of  support  routines  are  the  mathematical  tests  (e.g., 
trigonometric  functions)  which  allow  the  user  to  compare  characteristics  such  as  time 
and  accuracy  across  different  Ada  implementations.  The  tests  are  designed  to  measure 
compiler  correctness  as  well  as  object  code  size  and  speed. 

These  armonics  benchmarks  are  available  through  the  Data  and  Analysis  Center 
for  Software  (DACS)  library  located  at  Rome  Air  Development  Center  (RADC).  The 
DACS  library  functions  as  a  distribution  center;  no  on-line  help  is  available.  To  obtain 
the  armonics  benchmarks,  requests  should  be  sent  to: 

D.ACS 

RADC/ CO  HI) 

Crifhss  AFB.  NY  13441-57U0 

Attn:  Document  Data  Set  Ordering 

(315)  336-0937 

The  benchmarks  are  on  magnetic  tape  medium  and  are  available  at  a  nominal 
cost.  Requestors  must  also  sign  a  terms  and  conditions  statement  from  RADC.  Several 
CAMP  components  are  distributed  through  the  DACS  library:  requests  should  specify 
the  component  clearly  (i.e.,  CAMP  parts14,  armonics  benchmarks,  or  expert  system15). 


MThe  CAMP  parts  are  the  reusable  missile  software  parts.  See  Edition  2  Section  11.2. 

15The  CAMP  expert  system  was  built  to  aid  in  selecting  the  appropriate  missile  parts  and  constructing 
the  resultant  program 
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Section  25 

Simulation  and  Emulation  of  Systems  in  Ada 


Ada  was  not  designed  as  a  simulation  language.  However,  the  language  does  provide 
programming  constructs  that  enable  a  user  to  build  a  simulation  system  similar  to  what 
would  be  possible  with  a  simulation  language. 

Although,  simulation  languages  are  very  diverse,  they  will  all  provide  a  user  with 
simulation  control,  random  stimuli  generation,  and  statistics  collection.  Some  also  pro¬ 
vide  scheduling  and  garbage  collection.  Two  of  Ada’s  features  that  are  very  useful  for 
implementing  simulation  systems  are  tasks  and  packages.  Tasks  provide  a  way  to  do  con¬ 
current  processing,  and  the  task  rendezvous  allows  for  synchronizing  concurrent  entities. 
Packages  promote  modularity  in  addition  to  data  and  process  encapsulation. 

1  here  are  many  diverse  types  of  computer  simulation  used  today.  They  are  gener¬ 
ally  grouped  into  four  classes.  Monte  Carlo,  continuous,  discrete-event,  and  combined 
discrete-continuous,  each  with  a  special  type  of  system  that  it  is  used  to  model.  Ada  can 
be  used  for  any  of  these  types  of  simulation,  but  some  specific  applications  may  require 
specialized  run  time  system  support.  A  discussion  of  the  use  of  Ada  for  discrete  event 
simulation  can  be  found  in  SH087  ,  A&-S87  and  BRU84'.  The  general  conclusion  has 
been  that  although  Ada  has  some  weak  spots  (in  inheritance  and  garbage  collection  of 
allocated  task  bodies),  it  is  quite  veil  suited  for  this  type  of  programming. 

25.1  Simulation  vs.  Prototypes 

Simulation  and  prototyping  are  related  concepts.  Their  difference  is  mostly  one  of 
purpose.  Prototypes  are  generally  of  a  subset  of  an  implementation.  They  are  designed 
to  show  the  functional  capabilities  of  a  portion  of  the  system.  On  the  other  hand, 
simulations  usually  mimic  various  aspects  of  a  system's  behavior. 

At  times  a  simulation  will  be  used  with  a  prototype.  The  simulation  would  mimic 
the  environment  in  which  the  prototype  executes  its  functions.  The  relationship  between 
prototypes  and  simulations  is  analogous  to  the  one  between  a  module  and  its  test  driver. 

To  decrease  the  level  of  risk  on  projects,  the  use  of  prototyping  and  incremental 
releases  is  being  advocated.  Critical  portions  of  systems  are  prototyped  or  simulated 
early  in  the  life  cycle  to  determine  the  feasibility  of  the  system.  System  design  reviews 
often  include  demonstrations,  either  in  the  form  of  a  prototype  or  a  simulation. 
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25.2  On-going  Simulation  Work 

There  are  an  increasing  number  of  investigations  using  Ada  in  simulations.  In 
general  Ada  is  being  chosen  for  several  reasons: 

•  High  Order  Languages  are  easier  for  programmers  to  use, 

•  Ada  packages  enhance  modularity  and  maintainability, 

•  Ada  provides  multi-tasking, 

•  Ada  supports  dynamic  allocation  of  memory, 

•  Ada  has  an  interface  to  low  level  I/O, 

•  Strong  type  checking  prevents  data  in  low  level  modules  from  being  accessed  by 
accident, 

•  Record  types  provide  a  means  of  storing  arbitrary  types  of  data,  and 

•  Ada  supports  linked  list  manipulation,  needed  for  data  collection  and  event  calen¬ 
dar  management. 

Several  efforts  are  using  Ada  for  simulations  in  the  systems  area  as  well  as  the 
applications  area.  In  M&G87  .  a  general  purpose  discrete-event  simulation  package  is 
described.  A  queueing  network  simulation  package  is  discussed  in  HAS88-,  a  motor 
plant  simulation  in  KIM88  ,  and  a  spacecraft  dynamics  simulator  in  BGA88\ 

To  support  ESD’s  investigation  of  alternative  Battle  Management  Command,  Con¬ 
trol,  and  Communications  (BM/'C3)  architectures,  the  MITRE  Software  Center  is  in¬ 
volved  in  simulating  real-time,  space-based  battle  management  functions.  Their  simu¬ 
lating  software  displays  three-dimensional  state  vectors  on  a  workstation.  They  plan  to 
support  other  Strategic  Defense  Initiative  (SDI)  simulations  by  designing  the  framework. 
The  point  of  contact  for  further  information  is: 

SDI  Simulation 
The  MITRE  Corporation 
Burlington  Rd 
Bedford,  M A  01730 
(617)  271-4501 

Two  aircraft  training  simulators  were  redesigned  and  reprogrammed  in  Ada.  The 
objective  was  to  apply  a  modern  software  engineering  approach,  partitioning  the  system 
based  on  data  flow  and  object  abstraction  techniques.  Tasking  was  used  sparingly  in 
these  simulations  for  efficiency  reasons.  Further  information  is  available  through: 
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ASD/YWB 

Wright  Patterson  AFB,  OH  45433 
(513)  255-7177 
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Section  26 

Lessons  Learned  on  Ada  Projects 


The  Ada  language  has  been  used  on  projects  throughout  the  military  -  on  pilot 
projects,  applications  under  development,  and  deployed  systems.  In  some  cases,  the  use 
of  Ada  has  been  by  choice:  in  others,  it  has  been  required.  A  baseline  of  experience  is 
emerging,  and  the  consensus  is  that  Ada  systems  are.  in  fact,  feasible.  Ada  development 
is  bv  no  means  problem  free,  largely  due  to  immature  tools  and  to  the  need  for  new 
software  engineering  approaches  and  attitudes.  There  are  clear  benefits,  however,  from 
the  use  of  Ada.  The  distribution  of  time  in  the  life  cycle  is  altered,  with  a  greater 
proportion  of  time  being  spent  earlier,  in  the  design  phase,  with  the  result  that  the 
generated  code  is  more  correct. 

In  theory,  using  Ada  is  supposed  to  bring  all  sorts  of  benefits,  in  particular,  lower 
cost  and  improved  quality  of  source  code.  Practically  speaking,  however,  managers  who 
have  not  yet  undergone  the  transition  to  Ada  are  asking,  is  all  the  propaganda  really 
true?  In  reading  about  Ada  one  often  just  hears  the  two  extremes:  the  system  can  be 
done  in  Ada  or  the  system  cannot  be  done  in  Ada  because  Ada  is  too  big.  too  slow, 
etc.  Results  from  the  field  are  available,  and  this  section  will  try  to  present  the  lessons 
taught  by  this  early  experience  with  Ada. 

This  section  presents  a  summary  of  the  Government's  and  its  contractors'  experience 
with  Ada  projects.  The  project  database  represents  both  large  and  small  projects  in 
terms  of  money  and  si/e.  Different  aspects  of  Ada  experience  are  discussed  in  order  to 
give  a  better  perspective  on  what  to  expect  in  the  transition  to  Ada. 


26.1  Metrics 

The  ever  increasing  cost  of  and  demand  for  soft  ware  is  focusing  more  attention  than 
ever  on  software  productivity  and  quality.  Several  metrics  are  used  ranging  from  the 
the  program  si/e  in  lines  of  code  per  unit  of  time,  to  the  frequency  of  software  failure. 
Regardless  of  the  aspect  being  measured,  productivity  is  usually  defined  as  a  ratio  of  the 
outputs  produced  by  a  process  to  the  inputs  it  consumes  [BOE87,.  According  to  Boehm, 
the  greatest  problem  exists  in  defining  the  outputs.  Partly  because  of  the  deficiencies 
in  the  traditional  metric  of  delivered  source  lines,  alternative  units  of  measure  based  on 
program  complexity  have  been  advanced.  Current  efforts  are  aimed  at  establishing  a  sef 
of  baseline  metrics  to  help  project  personnel  monitor  the  quality  and  status  of  software 
projects  |KEN87  . 

Productivity  data  on  Ada  projects  is  becoming  available.  Because  of  the  newness 
of  Ada  technology  and  some  unwillingness  on  the  part  of  projects  to  release  data,  these 
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numbers  should  not  be  viewed  in  absolute  terms.  They  are.  however,  indicative  of  some 
important  trends  that  show  that  using  Ada  will  have  an  unmistakable  impact  on  software 
development  and  cost. 

26.1.1  Distribution  of  Effort  in  Different  Phases 

Numerous  data  collection  efforts  reveal  that  Ada  projects  are  front-loaded.  Both 
first  time  and  repeat  Ada  users  have  found  that  much  more  time  is  spent  in  the  design 
phases,  and  much  less  time  in  the  code  and  integration  phases.  The  traditional  distribu¬ 
tion  of  software  development  effort  across  the  design,  code  and  test/integration  phases  is 
40  20-40,  whereas  Ada  tends  to  be  more  50-15-35  [RE187r  Several  projects  have  found 
that  integration  took  less  effort  than  originally  planned. 

There  are  several  reasons  explaining  why  Ada  projects  tend  to  be  front-loaded. 
This  distribution  reflects  greater  attention  being  paid  to  software  ei  Ti..lering,  which 
encourages  greater  effort  and  thought  in  the  early  phases.  The  Ada  language  contains 
powerful  program  structure  features  which  are  available  to  the  designer  when  Ada  is 
also  used  as  a  PDL.  Ada  must  be  learned  earlier  in  the  life  cycle  than  other  languages, 
because  it  is  also  used  as  a  PDI.. 

The  distribution  of  effort  in  the  software  life  cycle  should  also  be  examined  from  the 
point  of  view  of  the  software  standards.  I'sers  have  noted  that  the  software  development 
standards,  including  DoD-S  I  D-2167,  are  not  wholly  compatible  with  Ada  software  de¬ 
velopment.  Complaints  focus  on  the  fact  that  they  do  not  allow  for  evolutionary  software 
development.  The  use  of  Ada  as  a  design  language  increases  the  problem  because  it  is 
difficult  to  differentiate  between  the  expression  of  the  design  and  actual  code.  Most  stan 
dards  require  that  the  PI)1.  be  frozen  before  any  code  starts.  The  use  of  Ada  compounds 
the  problem  because  in  Ada,  the  PDL  is  continually  refined  into  code.  In  the  course  of 
this  refinement,  changes  will  probably  need  to  be  made  to  either  the  requirements  or 
design,  and  when  the  design  is  expressed  in  an  Ada  PDL.  it  appears  to  be  duplication 
of  effort  to  update  one  set  of  files  representing  the  design,  and  an  almost  identical  set  of 
files  representing  the  design  as  partly  expanded  into  code. 

26.1.2  Productivity 

A  traditional  measure  of  productivity  is  in  delivered  source  lines.  In  earlier  lan¬ 
guages,  for  instance  FORTRAN,  a  line  held  a  whole  statement  (or  most  of  it).  In  Ada. 
free  formatting  is  encouraged  for  readability,  and  a  line  taken  literally  may  well  be  blank 
or  contain  only  a  small  part  of  a  statement.  Strictly  speaking,  there  will  probably  be 
many  more  lines  (in  the  sense  of  FORTRAN  card  images)  of  code  in  an  Ada  program 
than  in  a  program  in  some  other  language.  The  separable  characteristics  of  Ada  speci- 


26-2 


fications  and  code  provide  an  additional  quantity  of  semicolons  to  reflect  specifications 
and  context  clauses.  These  increase  the  semicolon  count  in  Ada  necessary  to  reflect  an 
equivalent  structure  in  some  other  language.  In  some  cases  this  could  be  a  26%  overhead 
in  Ada  and  quickly  offset  a  perceived  productivity  increase.  Furthermore,  additional  Ada 
language  constructs  are  used  to  define  context  and  interfaces  and  these  add  to  the  semi¬ 
colon  count  and  should  be  considered  when  comparing  an  Ada  effort  against  another 
language  such  as  FORI  RAN’.  Consequently,  a  revised  measure  is  emerging,  based  on 
counting  semicolons.  Various  considerations  apply  in  counting  semicolons,  as  noted  in 
RE  187  . 

Several  attempts  have  been  made  to  calculate  Ada  productivity  in  terms  of  semi¬ 
colons  per  person-month.  1  he  average  for  these  estimates  is  in  the  range  of  277  to  310 
H<CS87  and  RF.187  semicolons  per  person  month,  higher  than  the  industry  average  of 
200  lines  of  code  per  person-month.  Another  study  reports  a  23%  increase  in  produc¬ 
tivity  over  the  life  of  ari  Ada  project  FOF87  .  consistent  with  the  increase  reported  in 
the  Harbaugh  and  Reifer  studies16.  Reifer  acknowledges  that  there  is  a  fairly  wide  range 
of  productivity  numbers  collected  in  his  research,  reflecting  the  steep  learning  curve  for 
Ada.  The  important  lesson  here  is  the  trend  to  higher  productivity. 

The  higher  productivity  figures  must  be  interpreted  in  light  of  the  steep  learning 
curve  for  Ada.  Numerous  sources  have  found  that  the  productivity  gains  will  not  be 
found  in  the  first  two  or  three  Ada  projects  and.  in  fact .  the  first  couple  of  projects  may 
show  a  productivity  decrease.  Ada  requires  a  heavy  up  front  investment  in  training, 
tools,  and  experience  base.  The  theme  of  the  December  1987  SIGAda  conference  was 
Ada  usage,  and  many  of  the  articles  in  the  Proceedings,  as  well  as  studies  published  by 
the  Armed  Forces  Communications  and  Electronics  Association  (AFCF1A)  and  Defense 
Science  Board  AFC’87  and  DSB87  .  point  out  that  this  investment  is  part  of  the  cost  of 
the  transition  to  Ada:  an  investment  that  must  be  made  in  order  to  realize  the  benefits 
promised  by  the  use  of  the  Ada  language. 

26.2  Language  Objectives 

The  purpose  of  using  Ada  is  not  just  for  the  language  but  also  to  accrue  Ada's  long 
range  benefits  to  the  entire  software  engineering  effort.  In  looking  at  Ada  experiences, 
we  have  to  consider  not  only  the  programmers’  experience  with  individual  language 
features,  but  also  issues  like  design,  reusability,  portability,  language  use,  testing,  and 
maintainability. 

18HarbaughTs  data  covers  one  project,  the  Graphic  Kernel  System  (GKS)  Ada  implementation,  while 
Reifers  database  includes  41  projects 
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Lessons  learned  in  the  design  phase  fall  into  two  major  categories:  the  use  of  a 
design  method  derived  from  object-oriented  principles  and  the  use  of  Ada  as  a  design 
language.  In  general,  an  object-oriented  approach  refers  to  a  data-driven  design  philoso¬ 
phy.  Software  is  viewed  in  terms  of  objects  and  operations  on  these  objects,  rather  than 
along  strictly  functional  lines. 

The  danger  with  some  of  the  object  oriented  approaches  is  their  tendency  to  over 
simplify  the  design  process.  Criticisms  of  \arious  methods  include  jN&:S87y. 

•  Lack  of  guidance  on  designing  concurrent  processes. 

•  Too  deeply  nested  hierarchical  structure. 

•  Limited  domain  of  applicability  to  small,  well  defined  and  well  known  problems, 
and 

•  Awkward  and  impractical  strategy,  reflecting  more  art  than  engineering  discipline. 

Object-oriented  design  has  become  popular  in  the  industry  and  its  precise  meaning 
differs  among  different  people.  In  choosing  this  approach,  or  any  other  methodology, 
caution  should  be  exercised  to  make  sure  that  the  design  technique  provides  not  only  a 
disciplined  decomposition  of  the  internal  functions  but  also  guidance  on  “the  packaging 
of  software  modules  into  Ada  tasks,  packages,  and  subprograms  N&S87!.’1 

Ada  has  been  found  to  be  a  good  language  to  use  for  expressing  design.  Some 
projects  have,  in  fact,  used  Ada  as  a  design  language  and  another  language  as  an  imple¬ 
mentation  language.17  The  primary  reason  lies  in  the  program  structure  facilities  that 
exist  in  the  language,  in  particular  the  package  feature.  There  is  disagreement  within 
the  Ada  community  as  to  whether  full  Ada  or  restricted  Ada  should  be  used  when 
recording  a  design.  The  restrictions  are  aimed  at  preventing  the  designer  from  coding 
prematurely,  for  example  by  disallowing  statements  within  the  PDL.  Many  Ada  pro 
gram  design  languages  (PDLs)  define  classes  of  structured  comments  in  order  to  allow 
the  designer  to  express  other  information  which  is  not  direct]}  expressible  in  Ada,  such 
as  timing  constraints  and  input  assumptions.  (Edition  1,  Section  5  discusses  PDLs.) 

In  spite  of  this  drawback  to  using  Ada  as  a  PDL,  namely  the  risk  of  premature 
coding,  there  are  major  benefits  which  have  been  realized.  Assuming  that  the  PDL  can 
be  machine  processed  (often  bv  an  Ada  compiler),  syntactic  and  semantic  errors  are 
caught  much  earlier  in  the  software  life  cycle,  in  particular  interface  errors,  such  as  one 
module  calling  another  one  with  the  wrong  name  or  the  wrong  types  of  parameters. 
Because  the  PDL  and  the  coding  language  are  the  same,  creating  the  PDL  effectively 

,7Directive  3405  2  states  that  an  Ada-based  program  design  language  will  be  used  for  software  design 
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creates  the  code  skeleton.  Furthermore,  because  the  code  is  completed  through  successive 
iterations  of  refining  and  expanding  the  PDL,  the  software  development  process  is  more 
evolutionary  in  nature,  allowing  for  improved  error  detection  and  correction. 

The  point  to  be  made  here  is  that  a  compilable  PDL  should  be  used.  One  project 
has  said  that  they  suffered  because  their  PDL  was  not  compilable  and,  therefore,  certain 
clean  interface  errors  were  not  caught.  Many  published  articles  encourage  the  use  of  a 
machine  processable  PDL,  i.e.,  an  augmented  compiler  which  can  machine  process  the 
annotations.  Such  an  enhanced  compiler  would  not  need  necessarily  to  generate  code 
from  the  PDL. 

7  here  is  no  agreement  in  the  community  as  to  whether  Ada  should  be  used  during  all 
stages  in  the  life  cycle.  Some  analysts  feel  that  Ada  was  not  designed  to  express  system 
structure  or  system  constraints.  They  feel  that  graphics  or  some  other  annotations 
are  needed  to  capture  temporal  information  and  other  constraints.  A  very  persuasive 
argument  against  the  use  of  Ada  too  early  in  the  life  cycle,  such  as  during  requirements 
definition,  has  been  advanced:  Ada  is  part  of  the  solution,  and  requirements  definition 
involves  determining  what  the  problem  is.  It  is  not  a  good  idea  to  explain  a  problem  by 
describing  its  solution.  Also,  the  solution  process  must  be  defined  before  the  solution 
technology  can  be  selected.  Ada  is  a  tool,  not  a  process,  and  it  is  the  process  which 
implies  the  tools,  not  the  other  way  around. 

Neither  Ada  PDL  nor  object-oriented  methods  have  been  found  to  be  sufficient  on 
their  own.  Used  together  they  can  be  a  powerful  combination,  in  particular  when  the 
object-oriented  method  communicates  the  design  through  a  graphical  notation.  The  use 
of  integrated  tools  supporting  both  the  graphics  and  PDL  is  extremely  important. 

26.2.2  Reusability 

One  of  the  promised  and  highly  promoted  benefits  of  using  Ada  is  reusable  code. 
Ada  experience  to  date  shows  t  hat  reusability  does  not  happen  by  accident .  The  design  of 
the  software  must  have  reuse  in  mind,  and  management  must  plan  for  reusable  modules 
as  a  product.  Reusability  is  not  free;  in  fact,  one  study  shows  it  to  be  a  major  factor 
influencing  cost  arid  size  estimation  REI87  . 

In  discussing  reusability,  one  should  identify  the  level  of  reuse:  reuse  of  utilities 
versus  subsystems,  and  reuse  within  one  organization  or  within  the  superstructure  of 
the  organization.  Reuse  has  become  a  catch  phrase,  and  sometimes  it  may  only  refer 
to  utility  libraries.  Whenever  a  programmer  writes  a  generic  and  instantiates  it,  he  is 
"reusing"  code. 

Reuse  costs  time  and  money.  It  must  be  designed  into  the  system  and  it  affects 
design  decisions.  Edition  2.  Section  11.2  addresses  issues  of  motivation,  design,  and 
incentives.  In  designing  reusable  components,  it  is  imperative  to  do  a  t  horough  functional 
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domain  analysis.  This  analysis  should  be  done  as  a  cooperative  effort  between  domain 
expert(s)  and  software  engineers.  Management  must  plan  for  both  good  communication 
and  an  effective  retrieval  system.  If  other  projects  do  not  know  about  the  reusable 
components  and  cannot  access  them  easily,  reuse  will  not  occur. 

A  key  element  in  planning  for  reusability  is  the  creation  of  an  effective  library  and 
configuration  management  system.  The  Ada  program  model  consists  of  a  single  library. 
Different  Ada  projects,  each  with  their  own  library,  cannot  share  modules  easily  unless 
the  source  code  is  duplicated  for  each  project.  Should  these  reusable  units  be  changed, 
the  changes  must  be  both  propagated  to  each  reuser  and  recompiled  within  each  project 
library.  Tools  are  needed  to  facilitate  the  concept  of  multiple  libraries  JDAU871. 

Several  reusable  libraries  exist,  in  the  commercial  and  public  domains.  (See  Edition 
2  Section  14.)  In  addition,  there  are  two  major  government  funded  efforts  to  create 
reusable  components,  the  Common  Ada  Missile  Package  (CAMP)  for  missile  compo¬ 
nents  (Air  Force  Armament  Lab)  and  the  Reusable  Ada  Packages  for  Information  System 
Development  (RAPID)  for  a  library/retrieval  system  (Army  Information  Systems  Engi¬ 
neering  Command).  The  Software  Technology  for  Adaptable  Reliable  Systems  (STARS) 
program  is  expected  to  fund  a  reusable  software  repository.  It  is  significant  that  there 
is  sufficient  high  level  interest  to  create  the  environments  needed  to  support  reusable 
components,  as  manifested  in  these  three  government  sponsored  efforts. 

26.2.3  Portability 

There  is  limited  experience  in  porting  Ada  code.  Few  applications  have  been  ported 
across  different  host  machines.  Ada  tool  vendors  have  the  most  experience  in  porting 
Ada  code  insofar  as  they  offer  products  whi~h  'ur.  on  different  hosts.  As  with  most 
languages,  machine-independent  portions  of  code  are  easier  to  port.  Edition  2  Section 

11.3  discusses  portability  in  depth. 

An  important  consideration  in  porting  Ada  is  the  tool  set  on  the  targel  machine. 
In  some  cases,  the  development  and  execution  environment  are  different.  The  target 
environment  needs  an  adequate  tool  set  for  testing  and  debugging  purposes,  so  that 
productivity  losses  are  not  incurred.  When  the  development  and  support  environments 
are  different,  there  should  be  a  strong  relation  between  the  two.  ideally  a  cross  compiler. 
Without  such  a  facility,  all  code  needs  to  be  recompiled  after  it  is  ported.  In  theory, 
this  should  not  be  a  problem  but.  in  practice,  the  compilers  may  not  be  of  the  same 
maturity  and  will  not  necessarily  generate  code  of  equivalent  quality  for  all  Ada  con¬ 
structs.  Moreover,  there  are  risks  that  the  compiler  on  the  target  machine  cannot  handle 
optional  Ada  features  related  to  representation  specifications  (Chapter  13  of  the  Ada 
Language  Reference  Manual)  and  that  it  has  a  different  set  of  bugs  requiring  different 
workarounds  than  on  the  development  system. 
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Configuration  management  is  an  issue  in  portability,  especially  in  the  situation 
where  source  code  is  being  developed  on  several  machines.  Experience  indicates  that  a 
great  deal  of  automation  is  required  to  control  source  code  and  maintain  stable  baselines. 

Benchmarks  have  been  ported  frequently  and  have  required  some  editing  to  compile 
and  execute  successfully.  Compiling  benchmarks  for  the  first  time  may  reveal  errors  in 
the  compiler  or  in  the  benchmark.  The  benchmark  may  assume  pragmas  that  have  not 
been  implemented  on  a  given  system.  In  running  benchmarks  on  embedded  computer 
target  systems,  modifications  may  be  needed  in  order  to  link  to  the  target  input/output 
functions.  A  more  detailed  discussion  of  benchmark  experiences  is  in  Section  24  of  this 
Edition. 

26.2.4  Language  Use 

Users’  experiences  with  Ada  language  features  are  very  positive  with  respect  to 
Ada's  strong  typing  and  program  structuring  constructs  but  negative  with  respect  to 
existing  implementations  of  Ada  run  time  systems  and  Ada  s  tasking  paradigm.  Ada 
has  made  certain  application  code  more  efficient,  for  example,  slices.  The  use  of  Ada 
has  led  to  much  cleaner  implementations  of  the  designs,  which  are  easier  to  understand 
and  work  with  at  integration  time. 

The  biggest  problem,  however,  lies  in  immature  tool  sets  and  the  lack  of  efficient 
run-time  support.  Early  releases  of  compilers  did  not  support  the  machine-dependent 
interface  of  the  language,  causing  problems  for  many  real-time  applications.  Early  im¬ 
plementations  of  generics  resulted  in  too  much  code  expansion.  The  tasking  overhead, 
especially  that  for  rendezvous  and  the  associated  context  switching,  is  too  high  for  most 
applications.  A  high  level  of  CPE  reserve  is  needed  in  order  to  run  Ada  software.  Prob¬ 
lems  have  been  reported  with  the  implementation  of  Ada's  input /output  features  for 
some  applications.  Many  of  these  problems  have  been  resolved  in  subsequent  releases  of 
compilers. 

Run-time  systems  need  to  be  integrated  with  existing  libraries  and  system  services 
such  that  the  application  can  place  appropriate  calls  to  those  modules.  The  language- 
defined  interface  pragma  needs  to  be  supported.  Run-time  support  libraries  need  ad¬ 
ditional  flexibility  to  accommodate  custom  hardware  chips  as  well  as  built-in  test,  bit 
manipulation,  and  fast  interrupt  capabilities. 

The  Ada  Real-Time  Environments  Working  Croup  (ARTEWG)  has  studied  the 
deficiencies  and  requirements  for  Ada  run-time  support  extensively.  Their  recommen¬ 
dations  focus  primarily  on  tasking,  including  standard  application-specific  scheduling 
algorithms  packages,  language  clarifications,  and  guidelines  on  the  use  and  implemen¬ 
tation  of  task  priorities.  In  a  white  paper  published  in  the  December  1987  Ada  Expo 
Proceedings  ART87  ,  the  ARTEWG  discusses  shortfalls  in  current  Ada  run-time  tech- 


nology.  The  ARTEWG  advocates  systematically  addressing  these  problems  in  order  to 
develop  Ada  run  time  idioms  that  meet  embedded  system  space  and  time  constraints  as 
well  as  fault-tolerance,  distributed  computing,  and  multi  level  security  requirements. 

Although  these  inefficiencies  are  major,  experience  shows  that  they  are  not  necessar¬ 
ily  a  reason  not  to  use  Ada.  Workarounds  have  been  found  in  almost  all  instances.  The 
issue  of  excessive  tasking  overhead  is  being  addressed  by  individual  vendors,  and  the-  are 
various  solutions  being  proposed,  including  possible  language  changes18,  implementation- 
defined  pragmas,  and  interfacing  to  assembly  language  where  necessary.  Successive 
releases  of  tool  sets  have  been  showing  substantial  improvements  in  performance  and 
functions. 

20.2.5  Testing 

In  several  projects  which  gathered  statistics  on  error  rates,  it  was  found  that  the  use 
of  Ada  reduced  errors  by  2o%  to  30%.  Significantly  more  errors  were  found  before  the 
integration  phase,  in  several  instances  reducing  the  amount  of  time  spent  in  this  phase. 
This  reduction  in  errors  was  attributed  to  the  extensive  static  checking  performed  by 
the  Ada  compiler.  By  compiling  their  designs,  users  found  that  they  could  eliminate  the 
syntactic  and  semantic  errors  between  module  interfaces  early  in  the  software  life  cycle, 
without  the  difficulties  normally  encountered  during  the  integration  phase. 

Testing  Ada  programs  has  revealed  interesting  results.  The  use  of  certain  Ada  con¬ 
structs  such  as  exceptions,  generics,  tasking,  and  packages  requires  a  different  approach 
to  testing.  More  special-purpose  drivers  are  needed  in  order  to  conduct  unit  tests.  The 
nondeterminism  of  task  scheduling  makes  it  more  difficult  to  test  concurrent  programs 
because  the  failures  may  not  be  repeatable.  Testing  effectiveness  has  increased  due 
to  some  Ada  features.  The  information  hiding  supported  through  the  proper  use  of 
packages  has  reduced  regression  problems.  Strong  typing  and  program  unit  specifica¬ 
tions  have  automated  detection  of  interface  errors.  The  existence  of  exception  handling 
has  encouraged  programmers  to  think  about  potential  exceptional  situations,  thereby 
reducing  errors. 

Since  the  initial  release,  the  validation  suite  has  become  more  thorough  in  its  cov 
erage  of  language  features.  A  validated  compiler,  however,  is  by  no  means  a  guarantee 
of  a  perfect,  error-free  compiler.  The  validation  suite  tests  conformance  to  the  stan 
dard;  it  provides  no  guarantee  of  performance  or  adequate  -un-time  support.  Over  time, 
however,  with  successive  releases  of  the  validation  suite,  some  of  the  harder-to-test  fea¬ 
tures  are  being  covered.  For  example,  with  release  1.9,  there  are  tests  on  tasking,  Ada 

18The  International  Real-Time  Ada  Issues  Workshop  identified  several  areas  where  language  changes 
would  help  make  Ada  more  responsive  to  the  real-time  embedded  community,  such  as  fault-tolerant 
non-distributed  execution,  program  reconfiguration,  and  hardware  interrupt  priorities  ;WOR87j. 


Language  Reference  Manual  Chapter  13  features,  and  fixed-point  types.  As  discussed 
in  Edition  1.  Section  3.1,  however,  the  validation  suite  can  never  be  complete  and  test 
every  nuance  of  Ada. 

26.2.6  Maintainability 

Little  data  is  available  yet  on  the  cost  of  maintaining  systems  written  in  Ada.  Based 
on  the  fact  that  integration  is  easier  because  the  Ada  constructs  are  more  understand¬ 
able,  maintenance  should  also  benefit  from  Ada-coded  programs.  Software  managers 
expect  that  because  Ada  allows  for  a  better  representation  or  expression  of  software 
structure  and  function,  maintenance  should  be  easier. 

The  bigger  issues  in  maintenance  may  well  be  the  need  for  recompilation  and  for 
configuration  management.  Depending  on  the  interconnections  between  modules  and 
their  location  in  the  program  dependency  tree,  large  amounts  of  the  program  may  need 
to  be  recompiled.  In  other  languages,  such  massive  recompilation  would  be  more  char¬ 
acteristic  of  a  new  release  of  a  compiler  than  of  a  change  to  an  existing  module.  At  first 
glance,  this  may  seem  to  be  a  substantial  drawback  to  the  use  of  Ada.  To  the  contrary, 
this  forced  recompilation  will  catch  many  other  errors  which  might  otherwise  creep  into 
the  system,  namely  the  notorious  ripple  effect  errors.  Sophisticated  incremental  recom¬ 
pilation  tools  will  also  help  in  limiting  recompilation  by  analyzing  the  impact  of  code 
changes  and  only  making  those  units  obsolete  which  are  affected  by  the  change.  Good 
design  of  a  system  may  avoid  most,  if  not  all.  of  these  problems. 

The  need  for  configuration  management  throughout  all  phases  of  the  life  cycle  is 
important.  The  Ada  program  library  model  enforces  a  current  configuration  because 
the  insertion  of  an  updated  module  in  the  program  library  automatically  invalidates 
any  dependent  units  in  the  library.  Because  of  the  nature  of  large  systems,  however, 
more  sophisticated  configuration  management  has  been  found  necessary  in  order  to  track 
baselines,  versions,  and  variants.  Moreover,  such  a  system  must  track  not  only  code  but 
also  all  associated  documentation  (design,  requirements,  user  manual,  etc.).  Data  on 
several  projects  reveals  that  configuration  management  played  a  much  more  important 
role  than  anticipated. 

26.3  Tools  and  Training 

Recently,  tools  and  training  are  receiving  considerable  attention.  Ada  conferences 
regularly  have  exhibit  halls,  which  attract  at  least  as  much  attention  as  do  the  regular 
sessions.  Training  was  perceived  as  a  possible  cause  of  the  slowness  of  the  Ada  transition, 
and  the  AJPO  and  AFCEA  organized  a  task  force  to  investigate  the  problem.  The 
general  conclusion  was  that  training  per  se  was  not  the  reason  projects  had  had  problems, 
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but  that  tools  were  a  major  contributor. 

26.3.1  Impact  and  Adequacy  of  Tools 

As  stated  in  Section  26.2.4,  tool  immaturity  caused  many  of  the  problems  on  Ada 
projects.  Production  quality  language  tools  are  needed,  such  as  symbolic  debuggers  and 
tasking  analyzers.  Tools  to  automate  other  phases  of  the  life  cycle  are  also  needed,  such 
as  design  tools  to  manage  complexity  and  to  help  understand  vertical  and  horizontal 
relationships  in  the  software.  For  example,  a  dependency  analysis  tool  would  be  useful 
in  order  to  list  both  the  units  which  depend  on  a  given  unit  (in  order  to  determine  the 
modules  to  be  recompiled  should  this  unit  change)  and  the  units  on  which  a  given  unit 
depend  (i.e.,  the  ones  imported  through  with  clauses,  to  facilitate  debugging). 

Ultimately,  a  fully  integrated  environment  is  needed.  Users  with  more  integrated 
environments  have  experienced  much  higher  productivity  using  Ada  than  those  with 
poorly  integrated  tools.  The  development  environment  should  provide  sufficient  target 
support  to  allow  testing  and  debugging. 

Vendors  have  made  great  progress  with  Ada  tools.  Looking  back  over  the  history 
of  Ada,  the  first  goal  was  to  develop  validated  compilers,  ignoring  considerations  such 
as  speed,  object  code  quality,  and  run-time  efficiency.  Ada  compiler  development  has 
been  pushing  out  the  limits  of  compiler  and  run-time  system  technology.  Having  met 
the  first  goal  of  validation,  vendors  are  working  on  their  next  objective,  performance 
and  optimization.  Successive  compiler  releases  have  made  tremendous  gains  in  speed, 
efficiency  and  correctness. 

There  are  a  great  variety  of  host /target  combinations  today,  showing  that  industry 
believes  that  there  is  a  market  and  that  DoD  is  committed  to  Ada.  In  spite  of  the 
problems  that  have  existed  with  the  early  tools,  the  Ada  pioneers  in  the  user  community 
have  showui  that  Ada  is  possible.  Having  surmounted  many  obstacles  in  the  tools  area 
and  given  the  variety  of  tool  options  today,  they  stress  that  the  lack  of  a  compiler  for  a 
target  machine  is  a  poor  excuse.  One  of  the  recommendations  coming  from  these  users 
is  to  look  for  an  acceptable  tool  set  before  starting  the  project.  Developing  tools  at  the 
same  time  as  the  application  is  a  frequent  source  of  technical,  cost  and  budget  problems. 
These  users  also  stress  that  a  pragmatic  rather  than  a  purist  approach  is  needed.  In 
other  W'ords,  a  program  manager  should  recognize  that  most  of  a  program  can  be  done  in 
Ada,  and  that  it  is  acceptable  to  isolate  critical  portions  to  be  done  through  an  interface 
to  another  language.  Just  because  the  all  the  code  cannot  be  written  in  Ada.  it  should 
not  be  taken  to  mean  that  none  of  it  can  be  written  in  Ada. 
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26.3.2  Ada  and  Software  Engineering  Training 

In  both  government  and  industry,  different  levels  of  personnel  in  the  development, 
management  and  support  functions  require  training  in  aspects  of  Ada  and  software  en¬ 
gineering.  Technical  training  in  language  features  and  design  methods  is  needed  for  the 
software  engineers.  Managers  need  to  learn  about  the  impact  of  Ada  on  the  life  cycle 
and  its  effect  on  planning,  scheduling,  and  resource  allocation.  Furthermore,  they  must 
recognize  the  need  for  training,  both  for  management  and  non-management  people.  Sup¬ 
port  personnel,  including  acquisition,  configuration  management  and  quality  assurance 
personnel  need  some  familiarity  with  the  language,  the  software  process  and  software 
metrics. 

Both  government  and  contractor  personnel  agreed  with  the  need  for  different  kinds 
of  training  in  software  topics  for  different  categories  of  work.  Training  is  needed  not 
only  in  writing  software  as  an  engineering  discipline  but  also  in  a  life  cycle  approach 
to  software  management  and  control.  The  rotation  of  uniform  personnel  in  project 
management  positions  breeds  a  short  term,  a  two  to  three  year  view  of  a  program, 
rather  than  encouraging  a  long  term,  20  year,  life  cycle  attitude. 

Timeliness  and  hands-on  experience  were  found  to  be  key  factors  in  successful  Ada 
training.  \  ideotapes  and  computer-aided  instruction  were  found  to  be  much  less  effec¬ 
tive  teaching  vehicles.  Ada  language  training  too  far  in  advance  of  design  and  coding  lost 
much  of  its  effectiveness.  In  order  to  gain  a  deep  understanding  of  Ada  concepts.  labora¬ 
tory  exercises  were  invaluable.  The  access  to  the  compiler  enabled  students  to  overcome 
the  hurdles  of  a  new  language's  syntax  and  semantics  and  to  gain  confidence  in  the  use 
of  Ada  structures.  Practice  in  designing  package  specifications  was  characterized  as  an 
integral  part  of  a  successful  technical  training  curriculum. 

Ada  training  involves  retraining  and  teaching  programming  attitudes.  Some  con¬ 
cepts  are  hard  to  learn  for  programmers  with  a  FORTRAN'  or  assembler  background, 
such  as  those  related  to  strong  typing.  Recent  graduates  learned  the  Ada  language  faster 
because  of  their  academic  experience  with  Pascal  and  other  modern  languages. 


26.4  Management 

The  use  of  Ada  is  leading  to  changes  in  management  expectations  and  planning. 
The  transition  to  Ada  has  given  new  prominence  to  software  issues  such  as  reliability, 
maintainability,  reusability,  methodology,  integrated  toolsets,  etc.  Cost  estimation  and 
resource  allocation  for  Ada  projects  are  different  than  for  non-Ada  projects.  The  steep 
learning  curve  for  Ada  means  that  planning  for  the  initial  project  will  differ  from  planning 
for  subsequent  projects. 
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26.4.1  Cost  Estimation 


Existing  cost  estimation  models  will  need  to  be  recalibrated.  Elements  such  as 
reusability,  the  degree  of  real-time  processing,  the  learning  curve,  and  the  use  of  Ada 
program  structure  features  need  to  be  integrated  into  the  models.  Moreover,  as  the 
base  of  Ada  projects  grows,  the  weighting  factors  applied  to  the  cost  parameters  can  be 
better  computed.  Current  weighting  factors  are  no  longer  valid  because  of  the  different 
distribution  of  effort  observed  in  Ada  projects.  During  the  transition  period  for  Ada 
technology,  prior  Ada  experience  is  an  important  cost  factor  to  incorporate  because  of 
the  steep  learning  curve  characteristic  of  the  first  one  or  two  projects. 

26.4.2  Resources  Needed 

Management  planning  must  account  for  personnel,  software,  and  hardware  re¬ 
sources.  The  initial  Ada  investment  is  expensive,  involving  training,  tool  acquisition 
and,  in  some  cases,  larger  computers.  With  subsequent  projects,  the  need  for  major 
outlays  to  support  Ada  declines  substantially.  The  lack  of  experienced  Ada  designers 
and  programmers  on  initial  projects  adds  time  to  the  schedule.  Managers  have  a  choice 
of  training  their  own  engineers  or  of  hiring  already  trained  personnel.  In  order  to  insert 
Ada  technology  more  effectively  into  their  own  organisation,  managers  may  want  to  hire 
an  “Ada  guru”  as  a  technical  focal  point.  Where  a  successful  transition  to  Ada  has  been 
achieved,  there  has  been  a  broad-based  management  commitment  to  the  use  of  Ada. 

Many  projects  have  identified  a  need  for  integrated  tools  to  maximize  the  productiv¬ 
ity  gains  made  possible  by  Ada.  In  addition  to  production  quality  compilers,  integrated 
design,  metrics  and  configuration  management  tools  are  needed.  Such  extensive  automa¬ 
tion  adds  to  the  cost  of  the  first  few  Ada  projects  in  an  organization. 

26.4.3  Receptiveness 

Ada  has  been  greeted  both  with  enthusiasm  and  with  resistance  in  government 
and  industry  circles.  Acceptance  of  Ada  is  gaining,  with  the  realization  that  the  DoD  is 
committed  (evidenced  by  the  two  Directives  3105.1  and  3405.2)  and  with  the  availability 
of  more  mature  language  tools.  Some  projects  were  successfully  done  in  Ada  in  spite 
of  management  skepticism  (either  on  contractor  or  government  side).  The  commercial 
world  has  shown  interest  in  Ada,  and  several  companies  have  made  business  decisions 
to  convert  to  Ada,  convinced  of  Ada’s  long  term,  life  cycle  benefits.  The  Ada  language 
is  regularly  referenced  in  software-related  articles. 

Resistance  to  Ada  can  be  attributed  to  a  combination  of  psychological  and  technical 
factors.  Because  of  its  newness  and  the  lack  of  widespread  Ada  experience,  projecl 
managers  are  afraid  of  failure.  They  do  not  want  to  take  the  risk  on  their  system. 
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preferring  to  let  others  prove  the  technology.  The  Ada  technology  was  not  mature  when 
the  first  Ada  projects  started,  and  the  technical  difficulties  experienced  were  sizable. 
The  e  are  still  technical  challenges  today  that  require  innovative  solutions.  Ada  was 
initially  marketed  as  the  universal  problem  solver  for  the  software  engineering  crisis. 
Because  this  promise  was  not  fulfilled  immediately,  some  managers  became  skeptical 
about  Ada’s  capabilities. 

It  is  important  to  understand  that  the  Ada  language  alone  is  not  the  entire  solution; 
it  is  one  piece  in  a  much  larger  integrated  solution  which  encompasses  language,  tools, 
and  methods. 

20.4.4  Ada  Experience  Forums 

Several  case  studies  and  workshops  to  assess  Ada  experience  to  date  have  been 
conducted.  T wo  companies  were  contracted  to  redesign  and  redevelop  in  Ada  two  aircraft 
training  simulators.  Reports  on  their  experiences  were  published.  An  “Ada  Simulator 
Validation  Program  Workshop"  was  held  and  briefing  slides  are  available  through  the 
following  address.  Further  information  is  available  through: 

ASD/YWB 

Wright  Patterson  AFB.  OH  45133 

(513)  255-7177 

The  F.lectronic  Industries  Association  held  a  workshop  in  November  1987  which 
addressed  Ada  experiences  as  well  as  industry  questions  on  Dol)-STD-2167  and  DoD 
STD-2168.  The  Ada  Information  Clearinghouse  is  continuing  to  accumulate  a  database 
of  DoD  programs  currently  using  or  planning  to  use  Ada.  ]  hey  have  developed  a  survey 
form  to  collect  data  on: 

•  program  name  and  sponsor. 

•  point  of  contact, 

•  brief  functional  description  of  software. 

•  host  and  target  systems. 

•  tools  (compilers,  design  tools,  etc.) 

•  estimated  size, 

•  productivity, 

•  education  and  training, 
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•  life  cycle  costs,  and 

•  lessons  learned. 

The  Ada  Information  Clearinghouse  may  be  reached  at 

Ada  Information  Clearinghouse 
31)139  (1211  Fern  St.,  C-107) 

The  Pentagon 

Washington  D.C.,  20301-3081 
Attn:  Ada  Usage 
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Section  27 

Distributed  Processing 


A  distributed  system  is  a  collection  of  processing  nodes  connected  by  some  limited 
bandwidth  communication  medium.  Each  node  is  composed  of  one  or  more  processing 
elements  sharing  a  single  memory  space.  Communication  between  nodes  is  usually  done 
by  message  passing. 

Most  current  applications  are  composed  of  a  few  distinct  programs  that  are  dis¬ 
tributed  to  different  nodes.  These  programs  communicate  via  a  message  passing  pro¬ 
tocol.  There  are  new  machines  and  new  applications  being  developed  for  which  this 
approach  is  impractical  due  to  size  or  the  number  of  processing  elements.  This  section 
discusses  both  types  of  projects  and  their  relevant  issues. 

Historically,  there  has  been  another  class  of  systems  called  "tightly  coupled  dis¬ 
tributed  systems."  These  systems  are  composed  of  several  processors  that  communicate 
by  means  of  shared  memory.  Today  these  systems  are  usually  referred  to  as  multipro¬ 
cessors.  Ada  is  generally  considered  to  support  this  type  of  \vs1em  very  well,  and  most 
of  these  systems  have  an  Ada  capability. 


27.1  Current  Development  Issues 

'The  typical  distributed  application  today  runs  on  a  few  nodes  and  is  developed  as 
one  or  more  separate  programs  per  node.  Each  node  in  these  systems  is  either  a  single 
processor,  or  a  set  of  processors  that  share  a  common  memory  address  space.  Ada  is  well 
suited  for  developing  software  on  one  node,  and  the  details  of  internode  communication 
can  be  easily  hidden  in  one  or  two  packages  RA’Z83  and  DZM87  . 

I  here  are  several  areas  of  interest  for  this  type  of  distributed  application  in  Ada: 

•  local  area  network  interface. 

•  configuration  management. 

•  distributed  data  management. 

•  migration  of  data. 

•  migration  of  code,  and 

•  load  balancing. 
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The  most  popular  communication  system  for  distributed  systems  is  the  local  area 
network  (LAN).  These  networks  provide  relatively  high  bandwidth  communications  be¬ 
tween  nodes.  The  communication  software  for  most  of  these  networks  was  not  designed 
for  Ada,  and  some  of  the  Ada  interfaces  are  difficult  to  work  with.  There  are  no  inherent 
problems  in  creating  a  good  interface,  but  a  program  manager  should  plan  for  solving  a 
few  problems  when  interfacing  to  an  existing  product. 

Configuration  management  is  difficult  when  many  different  programs  must  interact 
in  a  consistent  fashion.  Spreading  programs  across  many  nodes  makes  this  problem 
even  more  difficult.  The  user  must  maintain  strict  control  over  the  version  of  each 
program  loaded  on  each  node  to  ensure  correct  system  operation.  Components  such  as 
communications  packages  that  are  used  by  several  programs  can  further  aggravate  this 
problem.  Configuration  management  is  a  major  factor  motivating  the  single  program 
approach. 

There  are  two  reasons  for  data  to  move  between  nodes,  performance  and  surviv¬ 
ability.  Data  can  be  moved  to  another  node  to  balance  the  load  across  the  system,  as 
discussed  later.  Data  may  also  be  replicated  on  many  nodes  to  provide  local  data  access 
(which  is  faster)  and  to  ensure  the  data  survives  the  loss  of  a  node.  Replicated  data, 
however,  may  require  very  expensive  support  iDDM87  . 

Migration  of  code  allows  a  node  to  do  the  processing  originally  allotted  to  another 
node.  Allowing  multiple  nodes  to  perform  any  particular  processing  allows  a  system  to 
survive  the  loss  of  a  node  or  to  balance  the  load  between  nodes,  thereby  increasing  overall 
throughput.  Several  issues  should  be  examined  if  this  mechanism  is  to  be  considered: 

•  How  long  does  it  take  to  move  the  code  from  one  node  to  another. 

•  How  much  does  this  cost,  and 

•  How  are  individual  processor  capabilities  matched  with  the  requirements  for  each 
unit  of  work? 

It  is  often  less  expensive  to  have  an  idle  copy  of  the  software  waiting  on  all  possible  host 
processors,  triggering  them  as  needed. 

Load  balancing  involves  shipping  data  and  code  between  nodes  to  even  the  load  on 
all  nodes  and  improve  system  throughput.  This  mechanism  can  also  be  used  to  allocate 
extra  resources  to  high  priority  work.  This  idea  has  some  merit  but  is  not  practical  for 
all  applications.  Often,  the  best  way  to  implement  load  balancing  is  to  replicate  the 
software  on  all  possible  nodes  and  trigger  execution  of  each  copy  by  moving  data  onto 
that  node.  In  this  case  load  balancing  only  requires  the  transfer  of  data,  not  code. 
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27.2  Single  Program  Models 


Many  people  are  currently  investigating  the  feasibility  of  a  single  program  approach 
for  distributed  systems.  When  a  single  program  spans  nodes  that  do  not  share  a  common 
memory  space,  communication  delays  and  communication  errors  between  the  elements  of 
a  program  become  common  events.  The  programming  language  and  associated  run-time 
system  must  provide  facilities  to  handle  these  situations. 

The  general  distributed  system  issues  discussed  in  Section  27.1  do  not  lose  their  im¬ 
portance  but  become  problems  that  must  be  solved  by  the  run-time  system  (as  opposed 
to  the  application).  While  this  can  create  problems  for  the  designers  of  the  run-time 
system,  it  does  relieve  the  application  programmers  of  a  significant  burden.  This  shift  in 
responsibility  may  be  a  mixed  blessing  however;  these  decisions  may  affect  the  capabil¬ 
ities  of  the  final  system.  Therefore,  application  programmers  may  need  to  retain  some 
control  over  the  resolution  of  these  issues. 

Most  single  program  efforts  involve  designing  a  distributed  processing  language 
such  as  Argus  LISS7  .  These  languages  generally  have  a  construct  that  serves  as  a  unit 
for  distribution;  for  Argus,  the  Guardian  construct.  The  semantics  of  this  construct 
facilitate  the  actual  distribution  of  program  elements  to  different  nodes.  Ada  does  not 
have  a  construct  well  suited  to  this  purpose.  This  lark  does  not  mean  that  Ada  is 
inadequate  for  this  type  of  programming,  only  that  the  problems  encountered  will  be 
more  difficult. 

The  first  decision  in  distributing  an  Ada  program  is  the  unit  of  allocation.  Several 
options  have  been  suggested: 

•  Tasks. 

•  Packages. 

•  Compilation  units,  and 

•  Inrestricted. 

Choosing  either  tasks  or  packages  leads  to  very  constrained  coding  styles.  For  example, 
if  a  task  is  chosen  as  the  distribution  unit,  then  each  task  must  be  associated  with  a 
processing  node.  The  only  way  to  have  any  data  or  code  resident  on  a  node  is  to  asso¬ 
ciate  this  data/code  with  a  task  on  this  node.  While  this  design  allows  communication 
protocols  to  be  built  around  the  rendezvous  mechanism,  there  are  nevertheless  serious 
problems.  First,  tasks  are  created  with  no  logical  meaning,  and  second,  code  and  data 
are  forced  into  tasks,  even  though  tasks  are  not  necessarily  the  most  appropriate  Ada 
construct.  Compilation  units  are  a  somewhat  better  choice  but  still  constrain  the  dis¬ 
tribution  scheme.  Honeywell  (  COR84  ,  KJE87  )  has  chosen  an  intriguing  method  of 
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allocation.  They  have  developed  a  distribution  language  that  allows  the  independent 
allocation  of  each  part  of  an  Ada  program. 

Data  allocation  to  a  particular  node  can  be  done  by  any  of  the  four  methods  men¬ 
tioned  above.  In  the  first  three  cases,  data  is  allocated  as  part  of  a  large  unit  that 
contains  both  program  and  data,  whereas  in  the  last  case,  data  can  be  allocated  inde 
pendently.  Once  data  is  allocated,  two  questions  arise: 

•  “How  does  one  reference  data  allocated  to  another  node?1',  and 

•  “Is  replicated  data  supported?" 

When  a  procedure  on  one  node  references  data  on  another  node,  problems  can  occur. 
First,  the  timing  behavior  of  variable  references  will  be  unpredictable.  More  importantly, 
there  is  no  mechanism  to  handle  either  long  delays  in  response  or  communication  errors 
involving  the  loss  of  the  read  request.  Special  purpose  mechanisms  can  be  built  into  a 
distributed  run-time  system,  but  they  will  limit  the  portability  of  the  resulting  software. 

The  replication  of  data  can  have  many  desirable  effects,  but  the  support  required 
for  it  to  meet  Ada  semantics  would  be  very  expensive  in  terms  of  processor  power  and 
system  survivability.  It  may  be  necessary  to  introduce  a  separate  piece  of  software 
such  as  the  Distributed  Data  Management  System,  discussed  in  DDM87J,  to  manage 
replicated  data  objects. 

Code  must  also  be  allocated  to  nodes.  Any  of  the  four  general  strategies  can  be 
used.  Code  replication  raises  some  interesting  issues.  There  are  two  types  of  code  in 
Ada:  code  that  cannot  be  executed  concurrently  (the  body  of  a  task19),  and  code  that 
can  be  executed  concurrently  (everything  else).  There  is  no  reason  not  to  replicate  a  sub¬ 
program.  but  replicating  a  task  could  significantly  change  the  meaning  of  a  program20. 
If  the  unit  of  allocation  is  a  package  and  the  package  contains  both  procedures  and 
tasks,  replication  may  be  difficult.  If  the  unit  of  allocation  is  a  task,  the  concurrency  of 
associated  procedures  may  be  unnecessarily  limited.  If  the  unit  of  allocation  is  a  task 
(each  task  and  its  related  procedures  are  allocated  to  a  particular  node)  the  concurrency 
of  associated  procedures  may  be  unnecessarily  limited.  When  several  task  objects  are 
generated  from  a  single  task  type,  these  objects  can  be  on  different  nodes  (and  therefore 
running  concurrently).  These  objects  can  be  allocated  to  the  same  node  or  different 
nodes,  however  any  single  object  can  reside  on  one  and  only  one  node.  The  implication 
is  that  in  order  to  interact  with  one  of  these  task  objects  the  code  must  go  through  the 
communication  process  on  the  node  on  which  the  task  object  resides.  However,  proce- 

1BAda  task  bodies  are  not  reentrant. 

J0Additional  code  would  be  needed  to  make  sure  that  while  the  task  is  running  on  the  first  node,  it 
has  not  also  started  running  on  the  second  node.  This  check  could  be  very  important  if  the  task  in 
question  were  protecting  a  shared  resource. 
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dures  associated  with  a  task  type  can  be  replicated  on  each  node  on  which  a  task  object 
of  that  type  is  located. 

Communication  to  a  remote  procedure  is  similar  to  referencing  a  remote  variable. 
Ada  does  not  prevent  it,  but  there  is  nothing  in  Ada  to  define  how  communications 
delays  or  errors  should  be  handled. 

Calling  an  entry  on  a  remote  task  can  cause  serious  problems  if  communication 
errors  are  encountered.  There  are  several  semantic  rules  about  entry  calls  that  can 
create  problems.  For  example,  the  time  limit  on  a  timed  entry  call  is  defined  in  terms  of 
when  the  call  enters  the  called  task's  entry  queue,  not  when  it  is  issued.  It  is  not  clear 
whether  a  time  out  could  ever  be  declared  due  to  lost  messages  or  other  communication 
problems.  If  the  call  is  delayed  by  the  communication  system,  it  is  not  clear  who  should 
time  the  call  out,  or  when  the  timeout  should  occur. 

The  single  program  approach  has  many  strengths: 

•  Ease  of  application  development. 

•  Reliability. 

•  Maintainability,  and 

•  Portability. 

It  also  has  some  important  difficulties  to  overcome.  Ada  is  not  the  perfect  language  for 
this  type  of  approach,  especially  when  timing  delays  become  long  and  communication 
faults  are  encountered.  Ada  can  be  adapted  to  t  his  environment .  however,  and  significant 
work  has  been  done  to  make  this  type  of  development  in  Ada  a  reality.  Honeywell,  among 
others,  has  done  significant  work  in  this  area. 
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Section  28 

Real-Time  Issues  in  Ada 


Real-time  systems  are  computer  systems  that  interact  with  ongoing  real  world 
events.  These  systems  differ  from  other  computer  applications  in  that  timeliness  is  as 
important  as  correctness.  Historically  the  production  of  real  time  software  has  been  ap¬ 
proached  quite  differently:  while  most  software  is  structured  according  to  its  functional 
requirements,  real-time  software  is  structured  according  to  its  timing  requirements.  This 
development  method  has  in  turn  led  to  high  integration  and  maintenance  costs. 

Since  the  advent  of  Ada.  there  has  been  intense  discussion  of  whether  or  not  real¬ 
time  systems  can  be  programmed  in  Ada.  The  principal  aspects  of  this  discussion  focus 
on  whether  traditional  development  techniques  can  map  inlo  Ada  constructs  and  on 
whether  Ada  implementations  can  generate  efficient  code.  Ada  has  the  features  to  sup¬ 
port  the  traditional  real-time  implementations,  as  discussed  in  Section  28.1.  Further 
improvements  are  needed  both  in  the  run-time  technology  and  real-time  system  devel¬ 
opment  methods  to  meet  the  severe  memory  and  time  constraints.  Recently  scientists 
have  been  investigating  other  ways  of  developing  real-time  software  to  reduce  cost  and 
increase  flexibility. 

28.1  Evaluation  of  Cyclic  Executive  Approach 

Classical  real-time  development  involves  the  production  of  a  cyclic  executive.  In  this 
scheme,  all  processing  is  assigned  specific  times  in  a  processing  cycle  that  is  executed 
repeatedly  (see  Figure  -1). 

Other  traditional  real-time  development  paradigms  exist.  Their  development  char¬ 
acteristics  are  similar  to  those  of  a  cyclic  system,  though  the  specific  mechanisms  may 
vary. 

28.1.1  Description 

A  cyclic  executive  is  a  mechanism  for  prescheduling  the  processing  in  a  system.  It 
provides  a  single  static  processing  schedule  that  has  been  specifically  luned  to  meet  the 
timing  requirements  of  the  application.  All  processing  to  be  performed  is  assigned  time 
in  a  schedule  of  finite  duration.  This  schedule  is  repeated  at  a  specified  rate,  known  as 
the  major  cycle.  The  major  cycle  is  broken  down  into  a  number  (usually  a  power  of 
two)  of  minor  cycles.  Each  minor  cycle  has  a  processing  frame  assigned  to  it.  A  frame 
is  a  list  of  processing  elements  to  be  performed  during  the  associated  minor  cycle. 

Flu  re  are  many  variations  of  cyclic  executives,  including  changing  frame  assign- 
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Figure  4:  Cyclic  Executive  Structure 
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ments  during  run-time,  alternatives  for  dealing  with  frame  overrun,  and  handling  inter¬ 
rupt  and  background  activities. 

Reasons  for  Choosing  this  Approach  A  cyclic  executive  approach  produces  code 
that  is  efficient  and  predictable.  These  are  key  requirements  for  most  real-time  sys¬ 
tems.  Many  real-time  systems  are  based  on  periodic  sampling  and  control  for  which 
the  cyclic  executive  is  ideally  suited.  Cyclic  systems  are  preplanned;  every  deadline  is 
anticipated  and  necessary  resources  are  allocated  in  advance.  Efficiency  is  achieved  by 
making  scheduling  decisions  prior  to  run  time.  Application  code  can  be  optimized  to 
take  advantage  of  the  inherent  synchronization  in  cyclic  systems.  (Synchronization  of 
access  to  shared  resources  is  done  prior  to  run  time.)  Timing  behavior  of  a  cyclic  system 
is  easily  analyzed:  the  time  for  each  frame  is  the  sum  of  the  execution  times  of  its  com¬ 
ponents:  the  time  limit  for  each  frame  is  a  minor  cycle.  Finally,  the  behavior  of  a  cyclic 
system  is  very  deterministic,  because  the  schedule  is  the  same  every  time.  The  timing 
of  th  e  system  cannot  vary  much,  a  highly  desirable  property  for  real  time  systems. 

Ada  Implementation  Highlights  Some  varieties  of  cyclic  executives  are  easily  im¬ 
plemented  in  Ada.  others  are  more  difficult.  MacLauren  MAC80  and  Hood  H0086 
show  how  a  number  of  cyclic  executives  can  be  written  in  Ada.  Implementation  prob¬ 
lems  are  encountered  when  an  executive  must  terminate  or  suspend  overrunning  frames. 
These  executives  can  be  written  if  they  are  adequately  supported  by  the  underlying 
run-time  system.  These  are  excellent  candidates  for  a  customized  run  time  system  as 
discussed  in  Edition  1  Section  3.3. 

28.1.2  Strengths  and  Weaknesses 

I  he  cyclic  executive  approach  is  very  good  for  producing  real-time  systems  that 
work.  These  systems  are  unfortunately  very  expensive,  both  to  produce  and  especially 
to  maintain.  Small  changes  in  software  function  or  computer  hardware  can  mean  massive 
changes  to  the  program.  All  possible  error  and  overload  conditions  must  be  foreseen  in 
advance.  Modifying  just  a  few  instructions  may  change  the  execution  time  characteristics 
of  the  program  so  that  the  entire  software  must  be  recalibrated.  It  is  not  uncommon  for 
seemingly  insignificant  changes  to  require  multi-million  dollar  programming  efforts  (for 
example,  changing  to  a  new  processor  that  is  identical  to  the  old  processor,  except  twice 
as  fast ). 
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In  summary: 


•  A  cyclic  executive  allows  for  precise  real-time  scheduling. 

•  Timing  analysis  is  easy  to  perform  and  timing  errors  are  detected  early  when  a 
frame  overruns,  and 

•  Cyclic  executives  are  expensive  to  produce  and  very  expensive  to  maintain. 

28.2  Evaluation  of  Data  Driven  Approaches 

Recent  work  has  focused  on  systems  that  meet  real  time  requirements  wilhout  the 
use  of  a  static  scheduling  structure  like  a  cyclic  executive.  This  work  is  exploring  sev¬ 
eral  new  technologies:  data  flow  machines,  functional  languages,  parallel  processing 
languages,  etc.  Ada  itself  reflects  an  attempt  to  move  in  this  direction. 

28.2.1  Description 

All  efforts  in  the  data  driven  methods  have  one  goal:  to  restore  the  functional  con¬ 
cept  to  real  time  systems.  The  techniques  proposed  to  engineer  this  restructuring  vary 
considerably.  Functional  languages  and  data  flow  machines  depart  from  the  Yon  Neu¬ 
mann  model  of  programming  by  taking  the  view  that  data  arrival  causes  an  instruction 
to  be  fetched  and  executed.  (Von  Neumann  machines  view  the  instruction  as  causing 
data  to  be  fetched  and  operated  upon.)  The  other  approaches  are  less  extreme  but  ren¬ 
ter  around  similar  ideas.  In  all  approaches,  the  flow  of  data  through  a  system  becomes 
an  important  factor  in  system  scheduling  decisions.  It  is  the  presence  of  data  which 
triggers  the  scheduler.  The  analogue  in  Ada  is  that  tasks  which  are  waiting  for  data 
to  be  passed  through  a  rendezvous  are  not  eligible  for  execution.  Thus  the  schedule  is 
nondeterministic,  introducing  an  element  of  unpredictability  into  the  system. 

Reasons  for  Choosing  this  Approach  The  data  driven  type  of  approach  creates 
real-time  software  with  a  functional  structure.  This  software  is  easier  and  cheaper  to 
create  and  maintain.  The  principal  reasons  are  that  the  software  is  inherently  more 
flexible  and  more  adaptable.  These  properties  not  only  lower  the  cost  of  today's  systems, 
but  without  them,  many  future  systems  (such  as  the  SDI  or  NASA's  Space  Station)  will 
not  be  possible.  These  systems  are  too  large  to  develop  as  a  single  piece:  the  software 
must  be  able  to  adapt  to  an  evolving  environment. 

Ada  Implementation  Highlights  Implementations  based  on  the  data  driven  model 
use  Ada  tasking  extensively.  Processing  is  coded  as  small  Ada  tasks  that  receive  data. 
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process  it,  and  send  data  out  as  they  finish.  If  references  to  shared  resources  (data  and 
hardware)  are  allowed  at  all,  they  are  strictly  controlled  by  monitor  tasks.  Specialized 
run-time  system  optimizations  of  elements  common  to  this  type  of  system  (such  as 
monitor  tasks)  can  greatly  improve  the  speed  of  this  type  of  system  (see  Edition  1 
Section  3.3). 

28.2.2  Strengths  and  Weaknesses 

This  type  of  system  does  not  suffer  from  the  problems  of  a  cyclic  system.  The 
data  driven  approach  enjoys  the  benefits  of  a  highly  modular  structure.  It  is  robust  in 
the  face  of  changes,  is  easy  to  maintain,  and  easy  to  adapt  to  new  environments.  On 
the  other  hand  it  lacks  the  efficiency,  temporal  determinism,  predictability,  and  ease  of 
timing  verification  and  testing  that  distinguish  a  cyclic  system.  Its  heavy  reliance  on 
Ada  tasking  incurs  the  penalty  of  frequent  context  switching  overhead  needed  to  support 
the  many  rendezvous.  As  the  data  load  on  the  system  increases,  the  likelihood  of  the 
system  thrashing  and  becoming  nonresponsi ve  increases. 


28.3  Temporal  Models 

The  critical  nature  of  timing  requirements  for  real-time  systems  has  motivated  re¬ 
search  in  the  area  of  temporal  models.21  By  developing  sophisticated  timing  analysis 
tools,  the  process  of  tuning  the  software  to  meet  its  timing  constraints  can  be  automated. 
Current  investigations  center  on  hybrid  systems  which  use  a  data  driven  development 
approach  and  a  cyclic  run-time  approach.  The  software  methodology  key  lies  in  the 
development  of  an  abstract  style  of  data  driven  programming,  without  unnecessarily 
constraining  the  temporal  behavior  of  a  program.  The  key  to  to  the  run-time  compo¬ 
nent  lies  in  creating  a  method  of  transforming  code  written  in  this  style  into  a  cyclic 
executive  system.  The  data  driven  code  provides  the  flexibility  and  adaptability,  and 
the  transformation  allows  the  final  system  to  take  advantage  of  the  predictability  and 
determinism  of  the  cyclic  structure. 


28.3.1  Processing  Models 

In  order  for  this  approach  to  work,  a  programming  style  must  be  defined  which 
allows  the  programmer  to  specify  all  temporal  properties  necessary  for  program  correct¬ 
ness  but  which  does  not  otherwise  constrain  the  program’s  timing.  This  approach  has 
been  called  the  processing  model.  This  model  defines  a  programmer  view  of  a  generic 
computer  resource.  Specific  machine  capabilities  and  specific  timing  requirements  are 

Jl  Model  of  the  timing  characteristics  of  a  piece  of  software 
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introduced  during  the  transformational  step,  through  which  detailed  timing  behavior 
is  derived.  The  processing  model  is  similar  in  many  respects  to  a  functional  language; 
however,  it  is  a  development  abstraction  only,  not  a  run-time  model. 

28.3.2  Transformational  Techniques 

Several  people  have  explored  transformational  programming  techniques.  Cheatham 
CHE84  ,  Boyle  B&M84;,  etc.  Transformation  into  a  cyclic  executive  can  build  on 
these  techniques  combined  with  the  methods  used  bv  today’s  real-time  designers  to 
create  cyclic  systems.  Ward  WAR78  discusses  a  system  that  uses  these  techniques  to 
transform  very  high  level  specifications  of  control  systems  into  real-time  systems. 

A  method  of  tuning  software  need  not  be  limited  to  cyclic  transformations.  While 
there  may  always  be  a  class  of  real-time  systems  that  require  cyclic  run-lime  perfor¬ 
mance,  there  are  other  systems  that  do  not  require  such  extreme  measures.  Many  of 
these  systems  would  benefit  from  the  flexibility  of  a  run-time  scheduler22.  These  systems 
still  require  tuning,  but  not  to  the  same  extent.  For  these  systems  other  tuning  trans¬ 
formations  can  be  used.  These  might  include  replacing  monitor  tasks  with  semaphores, 
or  simplifying  groups  of  tasks  using  program  inversion  techniques  RAJ83],  Using  these 
techniques,  a  system  can  be  tuned  until  the  appropriate  level  of  predictability  and  effi¬ 
ciency  has  been  reached. 

28.4  Run-Time  Environment  Technology 

It  is  generally  recognized  that  Ada  run-time  support  environments  are  immature. 
Shortfalls  exist  in  performance,  functionality,  and  flexibility.  Ada  run-time  systems 
provide  the  needed  support  to  pass  the  Ada  Compiler  Validation  Capability  tests  but 
lack  optimizations  for  memory  usage  and  throughput. 

The  problem  is  not  an  Ada  language  problem  but  a  run-time  support  problem. 
The  requirements  for  embedded  real-time  environments  are  being  analyzed  in  order  to 
develop  an  efficient  Ada  run-time  model.  For  example,  by  defining  in  t  he  run-time  system 
a  standard  set  of  low-level  tasking  primitives  supporting  deterministic  scheduling,  the 
programmer  gains  better  control  of  task  scheduling  and,  therefore,  of  system  timing.  An 
international  workshop  was  conducted  in  the  United  Kingdom  in  May  1987  to  discuss 
technical  issues  and  to  recommend  solutions,  where  a  consensus  could  be  achieved.  I  he 
workshop  Proceedings  |WOR87j  are  available  through  Ada  Letters.  The  discussions 
addressed: 

22A  run-time  scheduler  is  that  portion  of  the  operating  system  which  determines  the  order  of  execution 
of  application  code  and  system  software  services 
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predictable  scheduling, 


•  tasking  efficiency, 

•  distributed  processing,  and 

•  asynchronous  exceptions. 

A  second  Workshop  is  planned  for  1988. 

The  SIGAda  Working  Group  investigating  these  issues,  ARTEWG,  has  produced 
four  documents23: 

•  .4  Canonical  Model  and  Taxonomy  of  Ada  Run-time  Eniuronments, 

•  The  (\italogue  of  Ada  Run-time  Implementation  Dependencies, 

•  The  Catalogue  of  Interface  Features  and  Option  for  the  Ada  Run-time  Environ- 
me  nt.  and 

•  The  First  Annual  Survey  of  Mission  C'ritical  Application  Requirements. 

These  documents  may  be  obtained  by  writing  to: 

Mike  K  am  rad 

Honeywell  Systems  and  Research  Center 
M/S  MN 17-2351 
3660  Marshall  St.  NE 
Minneapolis.  MN  55518 
(612)  782-7321 

mkamradaAJPO.SEI.CMC.EDU 

On-line  information  on  ARTEWG  activities  is  available  in  the  directory  /artnews  on  the 
AJPO.SEI.CMU.EDU  machine. 


23 The  research  which  led  to  these  newly  released  publications  is  described  in  Edition  1,  Section  3.3.2 
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Section  29 

Contractor  Evaluation 


In  evaluating  a  contractor,  certain  general  qualities  should  be  present.  The  contrac¬ 
tor  should: 

•  have  a  complete  life-cycle  oriented  plan  for  management,  configuration  manage¬ 
ment,  and  quality  assurance, 

•  demonstrate  a  willingness  to  apply  and  write  reusable  components, 

•  show  correctness  and  usage  standards  for  code, 

•  practice  as  well  as  preach  methodologies, 

•  have  good  knowledge  of  software  tools  and  methodologies  to  promote  smooth  tran¬ 
sitions  between  phases,  and 

•  have  well-trained  and  supervised  personnel. 

Evaluating  program  development  plans  or  on-going  work  should  not  be  done  in 
a  vacuum  but  should  be  done  in  the  context  of  known  trends  from  previous  program 
evaluations.  Metrics  are  being  used  to  evaluate  projects,  and  the  resulting  information 
from  these  can  be  used  to  assess  contractor  development  plans  and  on-going  efforts. 

29.1  Software  Engineering  Exercise 

The  Software  Engineering  Exercise  (SEE)  was  developed  by  MITRE  to  aid  in  bidder 
evaluation  for  the  Air  Eorce  Electronic  Systems  Division  (ESD)  [AMN87].  It  is  used  to 
assess  a  contractor's  software  development  approach,  give  a  preview  of  what  will  be 
developed  during  the  contract,  and  identify  potential  problems. 

The  first  time  it  was  applied  to  a  source  selection  was  for  the  Command  Center 
Processing  and  Display  System  -  Replacement  (CCPDS-R)  program.  The  government 
identified  risks  that  would  be  associated  with  the  use  of  Ada,  in  particular  the  ability 
to  use  Ada  effectively  at  the  early  stages  of  software  development. 

For  the  CCPDS-R  program,  each  offerer  was  requested  to  “provide  a  prototype 
cal  example  of  the  bidder’s  proposed  software  development  approach.’’  The  purpose  of 
the  SEE  was  to  allow  the  government  to  assess  the  contractor’s  approach  through  its 
demonstration.  The  contractor  was  not  expected  to  prototype  an  actual  system  but 
to  prototype  the  practice  of  his  methodology.  The  exercise  was  conducted  following 
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DoD-STD-2167  guidelines.  The  government  evaluated  neither  all  the  phases  of  the  life 
cycle  nor  the  support  functions  such  as  quality  assurance  and  configuration  manage¬ 
ment.  The  evaluation  process  stressed  the  contractor’s  approach  to  management,  and 
to  the  requirements  and  design  analyses  phases,  as  reflected  in  the  products  required  of 
the  participants. 

MITRE  performed  a  dry  run  of  the  Software  Engineering  Exercise  prior  to  request¬ 
ing  it  of  the  offerers.  The  dry  run  helped  the  government  determine  what  to  request  of 
the  offerer,  what  guidelines  to  give  the  offerer,  and  development  of  technical  evaluation 
guidelines.  Also  from  the  dry  run  it  was  reaffirmed  that  the  following  three  things  require 
enhanced  management  attention:  requirements  analysis,  Ada  tasking,  and  managing  a 
development  team. 

The  following  items  were  stated  conclusions  learned  from  the  SEE: 

•  It  was  an  excellent  training  mechanism  for  the  government  participants. 

•  It  very  successfully  met  its  stated  objectives, 

•  It  resulted  in  improved  SDPs  and  more  knowledgeable  offerer  staff. 

•  It  required  considerable  government  preparation  and  careful  evaluation,  and 

•  It  was  a  software  engineering  exercise,  not  an  Ada  exercise. 

If  SEE  were  used  on  a  different  project,  it  would  need  to  be  modified  to  reflect  the 
requirements  of  that  particular  project.  For  the  CCPDS-R  program  the  SEE  was  used 
during  source  selection,  although  several  ESD  programs  are  considering  incorporating 
SEE  as  a  contract  task. 


29,2  Ada  Decision  Matrix 

Contractor  evaluation  involves  risk  assessment  along  technical,  acquisition  and  eco¬ 
nomic  lines.  A  disciplined,  objective  method  of  analyzing  the  risks  of  using  Ada  on  a 
program  is  needed.  A  probability  based  approach  has  been  developed  by  The  Aerospace 
Corporation  and  documented  in  BAK84I.  This  work,  known  as  the  Ada  Decision  Ma¬ 
trix.  has  since  been  automated.  The  point  of  contact  is: 

Dixie  B.  Baker 

The  Aerospace  Corporation 

M5-562 

El  Segundo,  CA  90245 
(213)  336-4059 


29-2 


T 


I 


The  Ada  Decision  Matrix  involves  a  project  risk  worksheet  and  a  risk  priority  rating 
worksheet.  1  he  project  risk  potential  is  essentially  a  measure  of  the  probability  of 
success,  in  other  words  the  probability  that  a  given  factor  is  not  a  risk  factor  for  the 
project.  By  weighting  the  confidence  levels  in  individual  criteria  with  their  priority,  an 
overall  confidence  rating  is  computed.  This  final  number  is  not  an  indication  of  the 
likelihood  of  success  or  failure  of  a  particular  project,  ll  is  an  indication  of  whether  the 
decision  to  use  Ada  will  entail  low  or  high  risk.  J  Ids  Ada  risk  must  then  be  evaluated 
against  other,  non  Ada-related  risk  factors  previously  identified  for  the  project.  Ideally 
several  evaluators  should  complete  the  Decision  Matrix  in  order  to  remove  individual 
biases  for  or  against  t  lie  use  of  Ada. 

Karh  worksheet  item  is  graded  on  a  scale  of  five  confidence  levels,  ranging  from  “very 
low"  (a  rating  of  0.0)  to  "very  high'  la  rating  of  1.0).  Guidance  criteria  are  provided 
to  aid  the  evaluator  in  selecting  the  appropriate  rating.  lopies  addressed  include  tool 
availability  and  quality,  staffing,  training,  life  cycle  management  procedures,  and  cost. 
In  order  to  arrive  at  the  prohabilitv  of  success  for  the  technical  factors,  the  evaluator 
may  first  want  to  probe  further  by  asking  i  he  kinds  of  detailed  questions  found  in  reports 
on  Ada  compiler  evalua’ ion .  such  io  kb  AM  and  Illl.MSO  . 


29.3  Process  Evaluation 

It  is  frequently  said  that  the  only  way  to  meet  the  ever  increasing  demand  for 
software  is  to  increase  productivity.  Increased  productivity  is  achieved  when  higher 
quality  software  with  fewer  errors  and  lower  maintenance  costs  is  produced.  Judicious  use 
of  metrics  helps  the  program  manag*  i  monitor  the  status  of  a  project,  ihe  productivity 
of  its  staff,  and  the  quality  of  ’he  "inputs. 


29.3.1  Metrics 

I  he  application  of  productivity  measures  and  quality  standards  has  been  the  focus 
of  much  attention  lately,  in  particular,  in  the  context  of  contractor  evaluation.  Ihe 
Defense  Science  Board  I  ask  Force  Report  on  Military  Software  DSB87  ,  for  example, 
st  rough.’  recommends  hot  h  t  he  use  of  met  rics  to  assess  soft  ware  quality  and  progress  and 
their  routine  incorporation  into  contracts. 

The  Air  force  Fleet  ronic  Systems  Division  (FSD)  has  developed  a  set  of  software 
reporting  metrics.  This  effort  was  motivated  by  software  acquisition  goals  as  well  as  Ihe 
Air  Force  System  Command  Product  Assurance  Initiative.  The  metrics  are  designed 
to  measure  technical  and  management  aspects  of  the  coding,  testing,  and  operational 
phases  of  software  development  KFNsT  .  I  hese  metrics  include: 
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•  program  size  (in  lines  of  code). 

•  staffing, 

•  software  complexity, 

•  development  progress, 

•  testing  progress, 

•  computer  resource. 

•  program  volatility. 

•  incremental  release. 

•  code  change  rate,  and 

•  problem  reports. 

1  he  use  of  these  metrics  needs  to  be  tailored  according  to  the  objectives  of  a  project. 
Metrics  are  statistics  and.  therefore,  they  should  not  be  interpreted  as  absolute  measures 
of  progress.  1  hey  are  good  trend  indicators  and  can  aid  the  government  in  monitoring 
contract  health.  In  all  cases,  it  is  important  that  the  government  and  contractor  com 
municate  clearly  and  understand  one  another’s  goals  and  positions.  When  metrics  are 
used,  both  parties  must  agree  on  the  purpose  of  the  metric,  the  data  to  be  gathered, 
and  the  definition  of  the  metric. 

29.3.2  Contractor  Capabilities 

Prior  to  contract  award,  contractor  evaluation  requires  evaluation  of  the  proposed 
processes  to  produce  the  software.  The  premise  is  that  given  a  quality  development 
process,  at  the  very  least,  acceptable  software  will  be  written.  Assuming  that  the  same 
processes  were  used  on  other  projects,  it  may  be  possible  to  evaluate  the  quality  of  those 
products  in  order  to  extrapolate  whether  the  organization  produces  reliable  software 
within  cost  and  budget. 

Management  control  is  a  cornerstone  of  the  software  process.  Financial  control  of 
the  project  alone  is  not  sufficient.  Program  management  is  required  not  only  to  coordi¬ 
nate  resources  but  also  to  enforce  the  use  of  software  engineering  standards,  methods, 
and  tools.  Management  must  address  the  software  issues,  including  methods,  reusability, 
efficiency,  correctness,  etc.  The  management  function  undertakes  planning  the  software 
project,  and  the  manager's  responsibilities  include  both  creating  a  realistic  schedule  and 
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developing  contingency  plans.  Schedules  should  not  be  based  on  the  assumption  of  per¬ 
fect  software  after  the  first  compilation.  lest  failures,  tool  inadequacies,  and  resource 
mismatches  should  be  accounted  for  in  the  planning  stages. 

The  quality  goals  and  acceptance  criteria  for  the  project  must  be  established  at  the 
beginning  of  the  project,  before  a  contract  is  even  signed.  The  contractor's  management 
plans  should  show  what  methods  will  be  used  to  achieve  which  goals  and  what  corrective 
actions  will  be  taken  when  a  goal  is  not  met.  The  metrics  to  be  used  to  validate 
progress  on  individual  goals  should  be  stated.  Moreover,  the  plan  should  address  how 
the  manager  will  use  the  metrics  to  exercise  control  over  the  project,  for  example,  to 
revise  the  estimate  to  complete.  In  other  words,  measuring  aspects  of  a  project  is  not 
sufficient;  the  use  of  the  metrics  should  be  incorporated  into  the  management  plan. 

The  software  methods  used  should  be  clearly  outlined.  The  methods  selected  should 
he  matched  to  the  application  area.  For  example,  for  extremely  complex  software,  the 
methodology  needs  detailed  guidance  for  analyzing  the  "middle  part;"  it  should  not  be 
vague,  relying  on  expertise  and  magic  instead  of  discipline.  1  he  methodology  proposed 
should  be  suited  to  the  use  of  Ada  as  a  design  and  programming  language.  Specifically, 
it  should  address  the  allocation  of  software  among  the  different  classes  of  Ada  program 
units,  in  particular  the  choice  of  packages  and  tasks. 

The  methodology  should  describe  technical  progress  metrics  in  order  to  track  what 
portion  of  the  analysis,  design,  testing,  etc.,  is  complete.  Often  such  metrics  are  ex¬ 
pressed  in  term-'  of  the  manager  s  idea  of  what  percent  of  the  activity  is  complete.  Such 
measures  tend  to  be  inaccurate.  A  more  appropriate  measure  is  based  on  earned  value, 
for  example,  number  of  subsystems  designed,  number  of  modules  on  which  code  reading 
has  been  done,  or  milestones  completed21.  Milestones  should  be  tailored  to  the  evolu¬ 
tionary  nature  of  Ada  development.  Software  development  phases  overlap,  making  it 
hard  to  freeze  all  modules  at  an  identical  level  of  refinement.  Critical  modules  should 
be  designed,  coded,  and  tested  first,  implying  that  they  may  be  ready  before  other 
subsystems  are  fully  designed. 

Review  of  the  draft  products  and  their  refinements  is  needed.  1  his  review  should  be 
performed  by  qualified  technical  personnel;  its  purpose  is  to  exchange  ideas  and  uncover 
errors  as  early  as  possible.  It  is  likely  that  several  methods  will  be  needed  in  order  to 
cover  the  entire  software  development  life  cycle.  The  outputs  of  one  may  not  necessarilv 
be  in  the  correct  input  form  for  the  succeeding  method;  therefore,  careful  thought  is 
required  on  how  these  methods  will  be  integrated.  Automation  of  methods  is  desirable 
in  order  to  facilitate  tracking  and  updating  of  the  products.  Such  automation  should 
include  some  sort  of  machine  processing  of  the  product  in  order  to  verify  conformance 

2,In  addition  to  major  program  milestones  such  as  preliminary  and  critical  design  reviews,  the  man¬ 
agement  plan  should  identify  individual  inmi-milestones  within  tasks,  for  which  “credit"  is  taken  as 
thev  are  completed.  Examples  include  monthly  status  reports,  internal  publication  of  white  papers, 
and  subsystem  start  and  completion 
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to  the  rules  of  the  method. 

Project  personnel  should  be  trained  in  the  process  and  methods  to  be  used  on 
the  project.  The  degree  and  level  of  training  should  be  appropriate  to  the  individual's 
role  in  the  project.  For  example,  the  program  manager  should  not  take  a  three  week 
Ada  language  course,  whereas  intensive  training  in  a  specific  design  analysis  method  is 
appropriate  for  senior  project  engineers. 

Quality  assurance  control  should  be  exercised  through  an  independent  reporting 
structure.  Quality  procedures  should  be  DoD-STD-2167  compliant,  addressing  the  prod¬ 
ucts  specific  to  each  phase,  including  reviews,  milestones,  code  and  documents.  They 
should  specify  acceptance  criteria  for  the  individual  software-related  items  and  detail 
checklists  to  be  followed  to  verify  that  these  standards  are  being  met.  There  should  be 
procedures  in  place  to  evaluate  the  application  of  the  selected  software  methodology  as 
well  as  to  exercise  management  and  technical  control  over  subcontractor  performance. 

The  contractor  should  have  a  comprehensive  configuration  management  plan.  The 
important  criterion  here  is  that  configuration  management  be  applied  to  all  phases  of 
the  software  life  cycle.  Typically,  the  source  code  configurations  are  carefully  managed, 
but  insufficient  care  is  given  to  the  management  of  the  other  elements  of  the  product 
being  developed.  Documentation  at  all  levels  should  reflect  the  software  as  built;  for 
example,  design  information  and  user  manuals  should  be  updated  when  a  code  change 
is  incorporated. 
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Appendix  C 

Points  of  Contact  for  Ada  Information 


(In  presentation  order) 


PIWG 


Production  Quality  Ada 
Compiler  Report 

Report  No.  TOR  0086(6002  03)  1 


A  pplicat  ion  of 
Production  Quality  Ada 
Compiler  Report 


Real  I  ime  Run-  I  irne 
Environment  Studies 


cai'wc; 


Jon  S.  Squire 

West inghouse  Electric  Corporation 
P.O.  Box  746 
M fS  1615 

Baltimore,  MI)  21203 
(301)765-3748 

benchmark  Oajpo.sei.cmu.edu 

Aerospace  Library 
Reports  Circulation 
(Ml -199) 

P.O.  Box  92957 

Los  Angeles.  CA  90009 

Lt  Kurt  MaschofT 

Si)ace  Division 

SI)  ALR 

P.O.  Box  92960 

Los  Angeles.  CA  90009 

(213)  643-1279 

( AN)  833-1279 

Rich  Kayfes 
Aerospace  C orporat  ion 
(Ml  065) 

P.O.  Box  92957 

Los  Angeles.  CA  90009 

(213)  336-6092 

Dave  Dikel 

Addamax  Corporation 
7799  Leesburg  Pike.  Suite  900. 
Tysons  Corner.  \  A  22043 
( 703)847-6755 


Cl 


Armonics  Benchmarks  DAOS 

RADC/COEI) 

Griffiss  AFB.  NY  13441-5700 
Attn:  Document  /  Data  Set  Ordering 
(315)  336-0937 

SDI  Simulation  The  MITRE  Corporation 

Burlington  Rd 
Bedford,  MA  01730 
(617)  271  4501 

Lessons  Learned  Briefing  ASD/YWB 

Wright  Pa'terson  AFB.  OH  45433 
(513)  255-71 77 

Ada  Information  Clearinghouse 
3D  139  (1211  Fern  St..  C-107) 

The  Peril  agon 

Washington  D.C..  20301  3081 
Attn:  Ada  I'sage 

Mike  K  am  rad 

Honeywell  Systems  and  Research  Center 
M  S  MM 7  2351 
3660  Marshall  St.  NE 
Minneapolis.  MN  55518 
(612)  782-7321 

mkamrad  j>  A.J PO.S El.CML  .EDI 

Ada  Decision  Matrix  Dixie  B.  Baker 

The  Aerospace  Corporation 

M5-562 

El  Segundo.  CA  90245 
(213)  336-1059 


ARTEWG  Activities 
and  Documents 


DoD  Ada  Programs 
Database 


